GHSA-CM26-5974-52H8
Vulnerability from github – Published: 2026-07-14 20:28 – Updated: 2026-07-14 20:28Summary
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.
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(GeneratorInputhas 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_updatesset on blocklist change). - Dead helper:
internal/pki/blocklist.go(Blocklisttype) is never used in non-test code — no server-side enforcement either.
Reachability (hop by hop)
- Operator clicks Block on host B (or B is compromised/offboarded). B's fingerprint enters the per-CA
blocklisttable. - Every other host A under the same CA polls
GET /api/v1/agent/updates; server returnsblocklist: [<B-fp>, ...]andhas_updates=true. - A's agent decodes
Blocklistthen discards it;poll()has no blocklist branch. - Even on a config re-render,
configgen.Generateemitspki: {ca,cert,key}with noblocklistkey (proven by PoC). - A's Nebula daemon has an empty blocklist and accepts handshakes from B's still-valid cert. B keeps full mesh access.
Impact
Revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.
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.
Remediation
- Add
Blocklist []safeStringtopkiSection(yamlblocklist,omitempty) andGeneratorInput; consider alsopki.disconnect_invalid: true. - Have the agent apply
updates.Blocklistby re-rendering/rewritingconfig.yml+ SIGHUP (same path asConfigYAML). Simplest: fold the blocklist into the server-renderedConfigYAMLso it flows through the existing write path. - Add a regression test asserting a non-empty server blocklist yields a
pki.blocklistentry in the agent's written config.yml.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/forgekeep/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61699"
],
"database_specific": {
"cwe_ids": [
"CWE-299",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:28:18Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nnebula-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\u0027s Nebula enforces certificate revocation ONLY through the `pki.blocklist` list in `config.yml` (no CRL/OCSP). The project\u0027s own code states this: `internal/pki/durations.go:15` \u2014 \"Revocation via the blocklist remains the immediate security control.\"\n\nThe 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:\n\n1. The agent decodes the `blocklist` JSON field into `UpdatesResponse.Blocklist` (`internal/agent/poller.go:33`) and then DISCARDS it \u2014 `poll()` applies `CertificatePEM`, `CACertPEM`, `ConfigYAML`, but never references `updates.Blocklist` (`internal/agent/poller.go:300-339`).\n2. The config generator has NO field to emit `pki.blocklist` \u2014 `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.\n\nResult: a blocked/offboarded/compromised host\u0027s certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime \u2014 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.\n\n### Affected components\n\n- 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).\n- 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).\n- 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).\n- Dead helper: `internal/pki/blocklist.go` (`Blocklist` type) is never used in non-test code \u2014 no server-side enforcement either.\n\n### Reachability (hop by hop)\n\n1. Operator clicks Block on host B (or B is compromised/offboarded). B\u0027s fingerprint enters the per-CA `blocklist` table.\n2. Every other host A under the same CA polls `GET /api/v1/agent/updates`; server returns `blocklist: [\u003cB-fp\u003e, ...]` and `has_updates=true`.\n3. A\u0027s agent decodes `Blocklist` then discards it; `poll()` has no blocklist branch.\n4. Even on a config re-render, `configgen.Generate` emits `pki: {ca,cert,key}` with no `blocklist` key (proven by PoC).\n5. A\u0027s Nebula daemon has an empty blocklist and accepts handshakes from B\u0027s still-valid cert. B keeps full mesh access.\n\n### Impact\n\nRevocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer\u0027s config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates `host.key`+`host.crt` can run stock slackhq/nebula directly, ignore the agent\u0027s 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.\n\n### Proof of Concept (benign)\n\n`internal/configgen/blocklist_poc_test.go` renders a fully-populated host config and asserts the output contains the `pki` section but NO `blocklist` key:\n\n```\n$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v\n=== RUN TestPoC_NMESH001_GeneratedConfigOmitsBlocklist\n CONFIRMED: generated config has a pki section but no blocklist key\n pki:\n ca: /etc/nebula/ca.crt\n cert: /etc/nebula/host.crt\n key: /etc/nebula/host.key\n ...\n--- PASS\n```\n\nThe agent half is verifiable by inspection: `poll()` has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.\n\n### Distinctness\n\nNOT 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 \u2014 the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or `pki.blocklist` generation.\n\n### Remediation\n\n1. Add `Blocklist []safeString` to `pkiSection` (yaml `blocklist,omitempty`) and `GeneratorInput`; consider also `pki.disconnect_invalid: true`.\n2. Have the agent apply `updates.Blocklist` by re-rendering/rewriting `config.yml` + SIGHUP (same path as `ConfigYAML`). Simplest: fold the blocklist into the server-rendered `ConfigYAML` so it flows through the existing write path.\n3. Add a regression test asserting a non-empty server blocklist yields a `pki.blocklist` entry in the agent\u0027s written config.yml.",
"id": "GHSA-cm26-5974-52h8",
"modified": "2026-07-14T20:28:18Z",
"published": "2026-07-14T20:28:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-cm26-5974-52h8"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/commit/0426e2f224a9b1e2029029bf923c93ed39d21cdb"
},
{
"type": "PACKAGE",
"url": "https://github.com/forgekeep/nebula-mesh"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "nebula-mesh: Certificate revocation is never enforced at the mesh"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.