GHSA-v2jf-442r-6mjh
nebula-mesh: Signed-poll nonce LRU is in-memory and bounded; replay survives restart + eviction
Blast Radius
github.com/juev/nebula-meshReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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:
- 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.
- 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:
- Persist nonces in SQLite keyed by
(host_id, nonce)withON 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). - 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/juev/nebula-mesh | all versions | 0.3.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/juev/nebula-mesh. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/juev/nebula-mesh to 0.3.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v2jf-442r-6mjh is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v2jf-442r-6mjh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-v2jf-442r-6mjh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-v2jf-442r-6mjh in your dependencies?
O3 detects GHSA-v2jf-442r-6mjh across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.