CVE-2026-61699: Nebula Mesh VPN Auth Bypass Vulnerability

CVE-2026-61699 Overview

CVE-2026-61699 is a trust management vulnerability [CWE-299] in nebula-mesh, a self-hosted control plane for the Slack Nebula mesh VPN. Prior to version 0.7.1, the control plane never propagated its blocklist into the config.yml distributed to Nebula peers. A host marked as revoked in the UI retained full overlay reachability to every peer under its Certificate Authority (CA) for up to 30 days on agents and 365 days on mobile clients. An attacker who exfiltrates host.key and host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and remain connected after operator revocation.

Critical Impact
Revoked or offboarded hosts retain full mesh access. Operator-visible state (UI shows blocked, audit log records revocation) is misleading and does not reflect actual network reachability.

Affected Products

nebula-mesh control plane versions prior to 0.7.1
Nebula agent deployments managed by vulnerable nebula-mesh installations
Nebula mobile clients managed by vulnerable nebula-mesh installations

Discovery Timeline

2026-09-04 - CVE-2026-61699 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-61699

Vulnerability Analysis

The vulnerability stems from an incomplete revocation workflow in the nebula-mesh control plane. Revocation is the only in-band mechanism intended to isolate a compromised or offboarded host from the mesh. However, the generated config.yml distributed to peers omits the per-CA blocklist entirely, so the underlying Nebula daemon never learns which certificate fingerprints to reject during handshakes.

An attacker who obtains host.key and host.crt can bypass the nebula-mesh agent altogether by launching the upstream slackhq/nebula binary with the exfiltrated credentials. Because peer configurations lack a pki.blocklist entry, every other host in the mesh continues to accept handshakes signed by the revoked certificate. The attacker retains lateral access to internal services on the overlay until the certificate expires naturally.

Root Cause

The control plane maintained blocklist state in its database and surfaced it through the UI and audit log, but the configuration generator (internal/configgen/generator.go) had no Blocklist field. The enrollment handler in internal/api/enroll.go never queried GetBlocklistForCA when producing peer configuration, so revocation state never reached the pki.blocklist section that Nebula uses to reject handshakes.

Attack Vector

Exploitation requires prior possession of a valid host keypair, typically retained by an offboarded employee or extracted from a compromised endpoint. The attacker runs stock Nebula with the exfiltrated host.crt and host.key, ignoring the nebula-mesh agent's HTTP 403/410 poll responses. Peers accept the handshake because their configurations contain no blocklist entries.

// Patch: internal/configgen/generator.go
CACertPEM string
CertPEM   string
KeyPEM    string

// Blocklist is the per-CA list of revoked certificate fingerprints.
// Emitted as pki.blocklist in config.yml so the Nebula daemon rejects
// handshakes from revoked peers (GHSA-cm26-5974-52h8).
Blocklist []string

// Patch: internal/api/enroll.go
// Emit the per-CA blocklist into pki.blocklist so the Nebula daemon
// rejects handshakes from revoked peers (GHSA-cm26-5974-52h8).
if host.CAID != "" {
    bl, err := s.store.GetBlocklistForCA(ctx, host.CAID)
    if err != nil {
        return nil, fmt.Errorf("get blocklist for config: %w", err)
    }
    input.Blocklist = bl
}

Source: GitHub Commit 0426e2f

Detection Methods for CVE-2026-61699

Indicators of Compromise

Nebula handshakes originating from certificate fingerprints previously marked as revoked in the nebula-mesh audit log.
Overlay traffic from hosts whose agents are returning HTTP 403 or 410 to control-plane polls but continue to appear active on peer lightning-house reports.
Nebula daemon processes launched from binaries outside the expected nebula-mesh agent install path.

Detection Strategies

Compare the nebula-mesh blocklist database against live peer connections reported by lighthouses and identify certificates that should be rejected but are still handshaking.
Inspect deployed config.yml files on peers for the presence of a populated pki.blocklist section matching the control-plane state.
Alert on discrepancies between the audit log (host marked blocked) and network telemetry showing continued VPN activity from the same certificate identity.

Monitoring Recommendations

Correlate control-plane revocation events with subsequent Nebula tunnel activity from the affected host identity.
Monitor for unexpected nebula process executions on endpoints, particularly those running outside the managed agent path.
Log and alert on 403/410 responses from the control-plane enrollment endpoint that are not followed by a tunnel teardown on the mesh.

How to Mitigate CVE-2026-61699

Immediate Actions Required

Upgrade nebula-mesh to version 0.7.1 or later, which emits the per-CA blocklist into generated peer configurations.
After upgrading, force a configuration refresh on every peer so the updated pki.blocklist reaches all Nebula daemons.
Rotate the CA and reissue certificates for any host suspected of exfiltrating host.key and host.crt during the vulnerable window.
Audit currently revoked hosts and confirm they are no longer reachable on the overlay after the patch is applied.

Patch Information

The fix is available in nebula-mesh v0.7.1. Technical details are documented in GHSA-cm26-5974-52h8 and the corresponding commit 0426e2f, which adds a Blocklist field to the configuration generator and populates it via GetBlocklistForCA in the enrollment handler.

Workarounds

Manually append revoked certificate fingerprints to the pki.blocklist section of every peer's config.yml and redistribute until upgrading is possible.
Rotate the underlying CA to invalidate all outstanding certificates when a compromise is suspected and immediate patching is not feasible.
Restrict outbound network paths for high-value services on the mesh using firewall rules that do not rely solely on Nebula certificate validation.

bash

# Example pki.blocklist entry in config.yml (workaround before patching)
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key
  blocklist:
    - "c99d4e0b3a...revoked-fingerprint..."
    - "a17f2b9c8d...revoked-fingerprint..."