CVE-2026-61699

nebula-mesh prior to 0.7.1 fails to enforce certificate revocation across the mesh: when an operator revokes a host, the blocklist is never propagated into any peer's config.yml, so the revoked host's certificate remains accepted by every peer under the same certificate authority until it expires (up to 30 days for agent-issued and 365 days for mobile-issued certificates). An attacker who has exfiltrated a host's key and certificate (host.key and host.crt) can connect using stock slackhq/nebula, ignore the control-plane agent's 403/410 poll responses, and retain full overlay reachability to all peers and internal mesh services even after revocation. The control-plane UI and audit log misleadingly report the host as blocked, giving operators false assurance that isolation succeeded. Any deployment of the self-hosted nebula-mesh control plane running a version prior to 0.7.1 is affected. No public proof-of-concept or known in-the-wild exploitation exists, and EPSS estimates only about a 0.2% probability of exploitation within 30 days.

What to do: Upgrade nebula-mesh to version 0.7.1 or later. Until upgraded, and for hosts revoked under earlier versions, treat revoked credentials as still valid until certificate expiry (30 days for agent, 365 days for mobile): rotate the affected host's key and certificate if it was compromised or offboarded, and manually verify that blocklists are present in each peer's config.yml. Monitor overlay traffic for hosts shown as blocked, since the UI and audit log may overstate the effectiveness of revocation.