CVE-2026-61699

Vulnerability in nebula-mesh allows privilege escalation due to missing access controls on many API endpoints. Any operator with an API key can access resources of other operators.

nebula-mesh from version 0.6.0 to before 0.7.2 allows non-admin operators (role user) to set allow_private: true on their own managed webhook subscriptions (POST/PATCH /api/v1/webhook-subscriptions). No admin check exists on this field. At delivery time, allow_private switches the dispatcher to an unguarded HTTP client, bypassing the private/loopback/link-local SSRF guard, letting a low-privilege operator make the server request internal addresses.

nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. From version 0.3.0 to before version 0.5.0, the nebula-mgmt Web UI host-creation path ignores both the server-wide enrollment_token_ttl security setting and per-network network_config.enrollment_token_ttl overrides. API host creation and token-regeneration paths use the configured TTL resolver, but POST /ui/hosts hardcodes now.Add(24 * time.Hour) for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours. This issue has been patched in version 0.5.0.

nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. From version 0.2.0 to before version 0.5.0, when OIDC is enabled, GET /ui/oidc/login is reachable without authentication and is registered outside the Web UI rate-limited auth routes. Every request creates a fresh random OIDC state value and stores it in an in-memory map for 10m. Expired states are swept lazily, but there is no rate limit or maximum live-state cap on the allocation path. An unauthenticated remote client can therefore grow OIDC.states for the full state TTL, bounded by request throughput rather than by configured auth rate limits. This issue has been patched in version 0.5.0.

nebula-mesh prior to version 0.3.8 has a vulnerability in the web handler renderMobileBundle that passes the real *pki.CAResolver directly into mobilebundle.Build. Inside Build, resolver.LoadByID decrypts the CA's ed25519 private key into a *pki.CAManager, but Build never calls CAManager.Wipe() on any return path. As a result, when a mobile-bundle request goes through the web UI and Build returns (especially on error), the plaintext CA private key remains on the Go heap, unwiped, until garbage collection. An attacker able to read process memory can recover the CA signing key, allowing minting arbitrary host certificates for the mesh.

nebula-mesh prior to version 0.3.8 stores operator session tokens in plaintext in the operator_sessions table (the token column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours. Anyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication.

nebula-mesh before version 0.3.7 has two authorization gaps: the blocklist is not checked at certificate sign/re-enroll time (it is keyed by fingerprint, so re-enrollment creates a new fingerprint), and renewal does not re-validate operator or CA status. A host that should no longer be trusted can obtain a fresh valid Nebula certificate.

Nebula Mesh versions 0.3.5 and below do not apply per-operator CA scoping in the web UI, allowing any authenticated non-admin operator to access resources belonging to other operators. This was partially fixed in GHSA-598g-h2vc-h5vg but the web UI was not covered.

nebula-mesh before version 0.3.2 sets HttpOnly and SameSite=Lax flags on cookies but never sets the Secure flag. A single plaintext request to the origin (e.g., operator on a LAN, mistyped URL, HTTP→HTTPS not strictly enforced, reverse proxy misconfiguration) discloses the session.

In nebula-mesh prior to version 0.3.2, a newly minted operator API key was exposed in the redirect URL, potentially leaking via Referer header, browser history, or proxy logs. This issue has been fixed in version 0.3.2.