CVE-2026-53603

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 prior to version 0.7.1 has a vulnerability where revocation is the only in-band mechanism to isolate a compromised host. Because the blocklist never reaches any peer's config.yml, a blocked host retains full overlay reachability to every peer under its CA for up to 30 days (agent) / 365 days (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host.

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 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.