CVE-2026-61699

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:

1. The agent decodes the blocklist JSON field into UpdatesResponse.Blocklist (internal/agent/poller.go:33) and then DISCARDS it, poll() applies CertificatePEM, CACertPEM, ConfigYAML, but never references updates.Blocklist (internal/agent/poller.go:300-339).
2. The config generator has NO field to emit pki.blocklist, pkiSection is only ca/cert/key (internal/configgen/marshal.go:42-46) and GeneratorInput carries no blocklist (internal/configgen/generator.go:23-52). So even the server-rendered config.yml shipped via ConfigYAML cannot 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.

Affected components

• Agent drops the blocklist: internal/agent/poller.go:33 (decode target), internal/agent/poller.go:300-339 (poll() applies cert/CA/config, never the blocklist).
• Generator cannot emit it: internal/configgen/marshal.go:42-46 (pkiSection{CA,Cert,Key}), internal/configgen/generator.go:23-52 (GeneratorInput has no blocklist), internal/api/enroll.go:255-330 (renderHostConfig, source of shipped ConfigYAML).
• Server correctly produces/ships it (proves intent): internal/store/sqlite.go:2034 (GetBlocklistForCA), internal/api/updates.go:182-191 (resp.Blocklist), internal/api/updates.go:277 (has_updates set on blocklist change).
• Dead helper: internal/pki/blocklist.go (Blocklist type) is never used in non-test code, no server-side enforcement either.

Reachability (hop by hop)

1. Operator clicks Block on host B (or B is compromised/offboarded). B's fingerprint enters the per-CA blocklist table.
2. Every other host A under the same CA polls GET /api/v1/agent/updates; server returns blocklist: [<B-fp>, ...] and has_updates=true.
3. A's agent decodes Blocklist then discards it; poll() has no blocklist branch.
4. Even on a config re-render, configgen.Generate emits pki: {ca,cert,key} with no blocklist key (proven by PoC).
5. A's Nebula daemon has an empty blocklist and accepts handshakes from B's still-valid cert. B keeps full mesh access.

Proof of Concept (benign)

internal/configgen/blocklist_poc_test.go renders a fully-populated host config and asserts the output contains the pki section but NO blocklist key:

$ 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

The agent half is verifiable by inspection: poll() has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.

Distinctness

NOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix CheckIssuanceAllowed is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers, the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or pki.blocklist generation.