CVE-2026-61699: nebula-mesh: Certificate revocation is never enforced at the mesh
nebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack’s Nebula enforces certificate revocation ONLY through the pki.blocklist list in config.yml (no CRL/OCSP). The project’s own code states this: internal/pki/durations.go:15 — “Revocation via the blocklist remains the immediate security control.”
The server side is fully implemented (computes per-CA blocklist via GetBlocklistForCA, returns it in the agent-updates response, sets has_updates=true when non-empty). The agent side was never implemented:
- The agent decodes the
blocklistJSON field intoUpdatesResponse.Blocklist(internal/agent/poller.go:33) and then DISCARDS it —poll()appliesCertificatePEM,CACertPEM,ConfigYAML, but never referencesupdates.Blocklist(internal/agent/poller.go:300-339). - The config generator has NO field to emit
pki.blocklist—pkiSectionis onlyca/cert/key(internal/configgen/marshal.go:42-46) andGeneratorInputcarries no blocklist (internal/configgen/generator.go:23-52). So even the server-renderedconfig.ymlshipped viaConfigYAMLcannot carry it.
Result: a blocked/offboarded/compromised host’s certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime — up to 30 days for agent hosts (DefaultAgentCertDuration) and 365 days for mobile hosts (DefaultMobileCertDuration). Blocking a host in the UI/API has no effect on the data plane.
References
Code Behaviors & Features
Detect and mitigate CVE-2026-61699 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →