high · 8.1CVE-2026-61699Jul 14, 2026

CVE-2026-61699: nebula-mesh Certificate Blocklist Never Enforced on Mesh Peers

Shubham Kandhare
Security Engagement Manager, SecureLayer7

Blocking a host in nebula-mesh has no effect on the network: the revocation blocklist is never written into any peer's config, so a blocked or compromised host keeps full mesh access until its…

Packagegithub.com/forgekeep/nebula-mesh
Ecosystemgo
Affected< 0.7.1
Fixed in0.7.1

The problem

nebula-mesh lets operators revoke a host by adding its certificate fingerprint to a per-CA blocklist. The server computes and ships that blocklist correctly on every poll response.

The agent side was never wired up. poll() in internal/agent/poller.go applies new cert, CA, and config payloads from the server response but silently discards updates.Blocklist. Separately, the config generator (internal/configgen/marshal.go) only emits pki.ca, pki.cert, and pki.key, so even a server-rendered config.yml cannot carry a pki.blocklist key.

The practical result: a blocked, offboarded, or compromised host retains full overlay connectivity to every peer under its CA for up to 30 days (agent cert lifetime) or 365 days (mobile cert lifetime). The UI shows the block as applied; the data plane ignores it entirely.

Proof of concept

A working proof-of-concept for CVE-2026-61699 in github.com/forgekeep/nebula-mesh, with the exact payload below.

bash
# Benign PoC: render a host config with a non-empty blocklist and confirm pki.blocklist is absent.
# From the advisory's internal/configgen/blocklist_poc_test.go (TestPoC_NMESH001):

$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v
=== RUN   TestPoC_NMESH001_GeneratedConfigOmitsBlocklist
    CONFIRMED: generated config has a pki section but no blocklist key
    pki:
      ca: /etc/nebula/ca.crt
      cert: /etc/nebula/host.crt
      key: /etc/nebula/host.key
--- PASS

# Attacker consequence: run stock slackhq/nebula directly with the
# exfiltrated host.key + host.crt after the operator blocks the host.
# Poll returns 403/410 to the agent, but the Nebula daemon never
# receives a blocklist update, so peer handshakes succeed unchanged.
nebula -config /path/to/stolen/config.yml

The root cause is a missing distribution and application path for the blocklist (CWE-299 / CWE-672). The server calls GetBlocklistForCA and sets has_updates=true, proving intent, but the agent's poll() function has branches only for CertificatePEM, CACertPEM, ConfigYAML, and RekeyRequired, with no branch for Blocklist.

The config generator's pkiSection struct (marshal.go:42-46) has only CA, Cert, and Key fields, so pki.blocklist can never appear in any rendered YAML regardless of server state. The helper type internal/pki/blocklist.go exists but is unreferenced in all non-test code, confirming the feature was stubbed and never completed.

Patch commit 0426e2f fixes both gaps: it adds a Blocklist []safeString field (yaml tag blocklist,omitempty) to pkiSection and GeneratorInput, then wires updates.Blocklist through poll() so it is folded into the next config write and SIGHUP cycle.

The fix

Upgrade to nebula-mesh v0.7.1 (patch commit 0426e2f224a9b1e2029029bf923c93ed39d21cdb). If an immediate upgrade is not possible, treat the blocklist as non-functional: rotate (revoke and re-issue under a new CA) rather than block, shorten DefaultAgentCertDuration as far as operationally tolerable, and use network-layer controls to isolate compromised hosts while the upgrade is planned.

Reporter not attributed.

References: [1][2][3][4]

Related research