Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-04T20:17:23.717Z",
  "pubdate": "2026-09-04T20:17:23.717Z",
  "executiveSummary": "The vulnerability is an unauthenticated denial-of-service (DoS) condition stemming from improper resource management within the nebula-mesh OIDC authentication flow. Specifically, the GET /ui/oidc/login endpoint permits unauthenticated remote attackers to trigger the allocation of memory-resident state objects without effective rate limiting or capacity constraints.\nBy continuously requesting this endpoint, an attacker can rapidly populate an in-memory map intended for OIDC state tracking. Because the application lacks a maximum cap on live states and utilizes lazy expiration, memory consumption will scale linearly with the attacker's request rate until the host exhausts available system memory (RAM).\nThis vulnerability affects nebula-mesh versions 0.2.0 through 0.4.9 when OIDC authentication is enabled. The primary risk is service instability or total process termination due to an out-of-memory (OOM) event. Exploitation requires only network access to the target's control plane interface, and no valid credentials are required to initiate the attack vector.",
  "technicalDetails": "The root cause of this vulnerability is the unbounded allocation of memory within the OIDC authentication handling logic. Specifically, the GET /ui/oidc/login endpoint is processed outside the scope of the Web UI's rate-limiting mechanisms, granting unauthenticated remote actors unrestricted access to a resource-intensive operation.\nUpon every request to the /ui/oidc/login endpoint, the application generates a unique random OIDC state string and stores it in an in-memory map. This map is designed to track OIDC handshake states with a Time-to-Live (TTL) of 10 minutes. The application relies on a lazy cleanup mechanism to purge expired entries from the map.\nThe vulnerability arises because the allocation path lacks a maximum capacity constraint (a cap on the number of concurrent OIDC states) and is not protected by the rate-limiting infrastructure that safeguards other authentication endpoints. Consequently, an attacker can issue a high volume of GET requests in rapid succession, forcing the application to store an arbitrary number of state objects simultaneously.\nThe attack flow follows these steps: 1) The attacker initiates an unauthenticated connection to the nebula-mesh control plane; 2) The attacker sends a continuous stream of GET /ui/oidc/login requests; 3) The server, failing to apply rate limiting, processes each request by creating and storing a new entry in the in-memory OIDC state map; 4) The cumulative size of the map grows unchecked, as the rate of insertion significantly outpaces the lazy sweep mechanism; 5) The memory footprint of the nebula-mesh process increases monotonically, eventually triggering OOM-killer intervention or process crash.\nBecause the state is stored in an in-memory map, the vulnerability is ephemeral to the process lifecycle; however, the impact is severe as it renders the service unavailable to legitimate users. The lack of authentication and the bypass of existing rate-limiting controls ensure that even resource-constrained attackers can effectively deny service to the control plane. This behavior persists in all versions from 0.2.0 to 0.4.9, where OIDC is active, regardless of the underlying infrastructure configuration."
}