Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Search

GHSA-339v-266x-79xr

MediumCVSS 4.9 / 10
Published Jul 9, 2026·Last modified Jul 9, 2026
Affected Components(0)

No affected components available

Description

Summary

Two related authorization gaps let a host that should no longer be trusted obtain a fresh, valid Nebula certificate, because nebula-mgmt does not re-evaluate revocation/authorization state at certificate issuance time — only at poll time.

1. Blocklist not enforced at sign / re-enroll time

internal/api/enroll.go:128 calls caMgr.Sign(...) without consulting the blocklist. The blocklist is only checked in the poll path (internal/api/updates.go:57, fingerprintInBlocklist). The blocklist is keyed by certificate fingerprint (internal/store/sqlite.go), so a re-enrollment produces a new fingerprint that is not in the blocklist.

mintEnrollmentTokenForHost (internal/api/hosts.go:491) authorizes the caller via canAccessHost but does not check the host status. There is no guard preventing a blocked host from transitioning back to enrolled (internal/store/sqlite.go, enrollHostInTx updates status unconditionally).

Impact: A host that an operator has blocked can be silently un-blocked by issuing a new enrollment token and re-enrolling — it receives a fresh certificate (new fingerprint) that passes all subsequent poll-time blocklist checks. Revocation is therefore not durable. Requires an operator action (minting a re-enroll token), so this is an integrity/operational-revocation failure rather than an unauthenticated bypass.

2. Renewal does not re-validate operator / CA status

Auto-renewal at poll time (internal/api/updates.go:285-319, signHostCert) reads host.Name, host.Groups, host.NebulaIPs from the DB and re-signs without checking whether the owning operator is still active or the CA still valid. DisableOperator (internal/store/sqlite_operators.go) revokes sessions and API keys but does not retire the operator's CAs, and pki/signer.go checks only CA cert time-expiry, not operator/CA status.

Impact: A host enrolled under an operator who is later disabled continues to renew its certificate indefinitely. Offboarding an operator does not cut off the hosts they provisioned.

Affected versions

Latest tagged release (v0.3.6) and main.

Remediation

  1. Call a blocklist/status guard inside handleEnroll and signHostCert before caMgr.Sign(...); refuse issuance for a host whose status is blocked or whose previous fingerprint is on the blocklist. Require an explicit unblock before re-enroll.
  2. At renewal, re-resolve the owning operator/CA status and reject renewal if the operator is disabled or the CA retired (force re-enrollment instead).

Discovery

Found during an internal source + offensive security audit (tracking issue #178). Adversarially cross-verified against the code paths above.

Risk Scores
Base Score
4.9

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability.

Threat Intelligence
4.9

Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.

EPSS
N/A

Probability that this vulnerability will be exploited in the wild within the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Related Vulnerabilities
  • CVE-2026-53602
    Alias

Browse More

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard