CVE-2026-61699 in nebula-mesh
Summary
by MITRE • 09/04/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in Slack Nebula mesh VPN control planes prior to version 0.7.1 represents a critical failure in the revocation mechanism for host certificates within a zero-trust network architecture. Nebula relies on mutual TLS authentication using X.509 certificates, where each node validates peers against its local configuration and certificate authority trust store. The core flaw lies in how revoked or offboarded hosts are handled during the synchronization of security policies across the mesh. Specifically, while the control plane correctly marks a host as blocked in its internal state and user interface, this revocation status is not propagated to the peer nodes via their config.yml files. Consequently, the blocklist that dictates which certificates should be rejected remains static on individual peers until they are manually reconfigured or undergo a full policy refresh cycle that may take up to thirty days for agents and up to 365 days for mobile clients. This delay creates a significant window of opportunity where compromised credentials remain valid within the overlay network, effectively bypassing the intended isolation mechanisms designed to contain breaches.
From an operational perspective, this flaw allows an attacker who has exfiltrated both the host.key and host.crt files from a revoked or offboarded system to maintain persistent access to the mesh despite administrative revocation efforts. The stock slackhq/nebula implementation does not strictly enforce real-time certificate status checks against a centralized revocation list during the TLS handshake process in the manner required for immediate isolation. Instead, it relies on the locally cached configuration which has not yet been updated with the latest blocklist entries. An attacker can run the standard Nebula binary and ignore any 403 or 410 HTTP poll responses that might indicate a revoked status from the control plane API. Because the peer nodes still trust the certificate presented by the compromised host, full overlay reachability is retained. This means the attacker retains access to all internal services on the mesh, including sensitive data stores and administrative interfaces, for an extended period determined by the maximum configuration refresh interval of the affected client type.
The security impact is severe as it undermines the fundamental principle of least privilege and rapid incident response in a zero-trust environment. The misleading operator-visible state exacerbates the risk; administrators may believe that revoking a host immediately isolates it, leading to false confidence in their security posture while the compromised asset remains active on the network. This discrepancy between administrative intent and actual enforcement allows for lateral movement, data exfiltration, and potential persistence within the infrastructure long after the initial compromise has been detected. The vulnerability aligns with CWE-613, Insufficient Session Expiration, as it involves the failure to properly invalidate authentication credentials in a timely manner relative to their revocation status. Furthermore, from an ATT&CK perspective, this flaw facilitates Persistence and Lateral Movement techniques, specifically Tactic TA0003 (Persistence) through maintained access via valid certificates, and Tactic TA0008 (Lateral Movement) by allowing the attacker to traverse internal services that should have been inaccessible post-revocation.
To mitigate this vulnerability, organizations must upgrade their Nebula control plane and client agents to version 0.7.1 or later, where the revocation mechanism has been corrected to ensure immediate propagation of blocklist updates to all peers. Until such an upgrade is feasible, administrators should manually trigger configuration refreshes on critical nodes to reduce the window of exposure, although this does not fully resolve the issue for mobile clients with longer intervals. Additionally, implementing strict network segmentation and micro-segmentation policies can limit the blast radius if a host remains connected despite revocation attempts. Regular audits of certificate validity periods and automated monitoring for anomalous traffic from revoked hosts are also recommended to detect any exploitation of this flaw in real-time. The patch addresses the root cause by ensuring that the blocklist is dynamically synchronized across all peers, thereby enforcing immediate isolation upon revocation as intended by the security design.