Description

nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. Prior to version 0.7.1, revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (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. Operator-visible state (UI shows blocked, audit log records it) is misleading. This issue has been patched in version 0.7.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-04T20:17:24.347Z",
  "pubdate": "2026-09-04T20:17:24.347Z",
  "executiveSummary": "nebula-mesh versions prior to 0.7.1 contain a critical security flaw regarding host revocation mechanisms. The vulnerability allows a compromised or offboarded host to maintain unauthorized network access to the mesh overlay despite being marked as blocked within the control plane.\nThe vulnerability type is an authorization bypass, specifically resulting from an ineffective implementation of revocation propagation. While the nebula-mesh UI and audit logs correctly reflect the blocked status of a host, the underlying Nebula protocol configuration does not synchronize this state to peer nodes.\nThis creates a significant risk as the blocklist remains isolated to the control plane, rendering the revocation effectively non-functional against adversaries who possess the host.key and host.crt. An attacker can circumvent the control plane's signaling by using standard slackhq/nebula clients, ignoring revocation responses, and persisting within the network. This results in a total failure of identity revocation, allowing continued lateral movement and unauthorized access to internal services for the duration of the certificate's validity period (up to 365 days for mobile or 30 days for agents).\nThis vulnerability is particularly dangerous because it provides a false sense of security to operators, who believe hosts have been isolated when they remain fully functional within the mesh.",
  "technicalDetails": "The root cause of this vulnerability lies in the decoupling of the nebula-mesh control plane's revocation status from the actual packet-filtering enforcement mechanisms on the individual peer nodes. In the standard slackhq/nebula architecture, security is enforced via cryptographic identity (certificates). When nebula-mesh revokes a host, it signals this via in-band polling; however, it fails to update the configuration of legitimate peers to explicitly reject or drop packets from the revoked certificate.\nThe exploitation flow is straightforward for an attacker who has exfiltrated the 'host.key' and 'host.crt' files from a compromised host. Upon an operator triggering a revocation, the nebula-mesh agent on the compromised host will receive a 403 or 410 error code during its periodic polling of the control plane. An attacker can trivially bypass this by ignoring the agent's signal and utilizing the original slackhq/nebula binary to establish connectivity directly.\nBecause the blocklist is never pushed to the 'config.yml' files of other peers, the other nodes in the mesh have no cryptographic or configuration-level reason to reject the revoked host. The network continues to route traffic from the revoked host because the certificate remains cryptographically valid within the CA hierarchy, and the peers are unaware that the control plane has invalidated the entity.\nThe attack is characterized by the following steps:\n1. An adversary exfiltrates the identity material (host.key and host.crt) from a target host.\n2. The operator identifies a compromise or offboards the user, marking the host as 'Blocked' in nebula-mesh.\n3. nebula-mesh updates the audit logs and UI, but fails to push any blocking policy (such as a CRL or updated certificate whitelist) to the remaining mesh participants.\n4. The adversary continues to interact with the mesh using standard slackhq/nebula software, bypassing the control plane's revocation responses.\n5. The adversary maintains full reachability to all peers under the same CA, effectively nullifying the revocation action.\nThis persistence allows the attacker to maintain access to sensitive internal services for the remaining life of the certificate. Since the peer-to-peer nature of the Nebula mesh does not inherently check the control plane for every connection attempt, the host remains 'authorized' until the certificate expires naturally. This requires no additional privileges to exploit beyond possession of the stolen credentials."
}