Vulnerability Database

362,176

Total vulnerabilities in the database

nebula-mesh: Signed-poll nonce LRU is in-memory and bounded; replay survives restart + eviction — github.com/juev/nebula-mesh

Authentication Bypass by Capture-replay

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.

  • Published: Jun 26, 2026
  • Updated: Jun 27, 2026
  • GHSA: GHSA-v2jf-442r-6mjh
  • Severity: Low
  • Exploit:
  • CISA KEV:

No technical information available.

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.