GHSA-v2jf-442r-6mjh nebula-mesh: Signed-poll nonce LRU is in-memory and bounded; replay survives restart + eviction

• Go github.com/juev/nebula-mesh: < 0.3.4 → fixed in 0.3.4

`internal/api/pop/nonce.go:25,40,86` + `internal/api/server.go:38` — the signed-poll nonce cache is an in-process LRU sized at 65,536 entries. `internal/api/updates.go:31` sets `pollClockSkew = 5 * time.Minute` as the replay window. Affected All released versions through v0.3.0 that have shipped the ADR 0004 signed-poll path. (If this is gated behind a feature flag, on a side branch, or not yet on a release tag, please flag — this advisory may not apply to the released artifact yet.) Threat model A captured signed-poll request can be replayed: 1. After any process restart — the in-memory LRU is wiped, so the original nonce becomes "unseen" again. Replay succeeds if the original timestamp is still within the 5-minute skew. 2. After forced eviction — an attacker with control of any single host can flood >65,536 nonces under their own host_id, driving the global LRU to evict the victim's recorded nonce. Replay then succeeds. Impact is bounded: a replayed poll fetches the `/api/v1/agent/updates` body. That body can include a freshly-minted enrollment token if a rekey is pending (`updates.go:249-260`) — at which point the attacker holds a single-use token they can redeem under their own keypair. Suggested fix Two options, either acceptable: 1. Persist nonces in SQLite keyed by `(host_id, nonce)` with `ON CONFLICT DO NOTHING`, retained for the timestamp-skew window. Adds one transactional INSERT per poll; bounded by the skew window (~5 min worth of rows server-wide). 2. Per-host cap on the LRU instead of a global 65k cap, so one host cannot evict another's records. Combined with shorter skew (≤30s) to bound the post-restart replay window. Option 1 is more robust; option 2 is lower-implementation-effort.