GHSA-598g-h2vc-h5vg is a critical-severity (CVSS 9.9) CWE-862 vulnerability in github.com/juev/nebula-mesh. O3 Security confirms whether GHSA-598g-h2vc-h5vg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
nebula-mesh: API endpoints lack ownership checks, enabling cross-operator privilege escalation
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-598g-h2vc-h5vg.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-598g-h2vc-h5vg plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 368,543 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/juev/nebula-meshReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
The /api/v1/* route surface trusts the bearer token alone for authorisation on most endpoints. The codebase itself admits this at internal/api/hosts.go:384: "API trusts the bearer token for authorisation; per-CA ownership is enforced only in the Web layer."
The Web UI gates state-changing routes through loadAccessibleCA (internal/web/cas.go); CA-management endpoints in internal/api/cas.go ALSO have proper canAccessCA gates. The gap is on the host, network, firewall, mobile-bundle, and most operator endpoints. Combined with the per-operator CA model from ADR 0002, this gives any non-admin operator API key broad cross-tenant access — instant privilege escalation in the worst case.
Affected
All released versions prior to v0.3.4.
Exploit chain
A) Mint admin API key from any operator key (instant privilege escalation)
internal/api/operators.go:118 — handleCreateOperatorAPIKey does no admin check and no actor/target-operator ownership check. Any operator key can call it for any operator (including admins) and receive a fresh bearer.
curl -X POST -H "Authorization: Bearer <low-priv-key>" \
https://server/api/v1/operators/<admin-id>/api-keys \
-H 'Content-Type: application/json' -d '{"name":"oops"}'
# Returns: {"key":"<32-byte admin bearer>","entry":{...}}
Reuse the returned key for subsequent requests → full admin.
B) Cross-operator host takeover via reenroll
internal/api/hosts.go:321,330 → mintEnrollmentTokenForHost. Looks up host by URL param, mints a single-use enrollment token, returns it. No ownership check.
curl -X POST -H "Authorization: Bearer <low-priv-key>" \
https://server/api/v1/hosts/<victim-host-id>/reenroll
# Returns: {"enrollment_token":"<uuid>",...}
Caller POSTs /api/v1/enroll with their own X25519 + Ed25519 keypairs. enroll.go:175 overwrites signing_pub_pem; SaveCertificateAndEnrollHost overwrites the cert. Legitimate agent's next signed poll fails bad_signature. Attacker now owns the victim's Nebula identity.
C) Cross-tenant CRUD on hosts, networks, firewall
The same gap applies across:
/api/v1/hosts*— create, list, get, update, delete, block, unblock/api/v1/networks*— create, list, get/api/v1/networks/{id}/firewall— get, PUT/api/v1/hosts/{id}/mobile-bundle(already filed as public issue #119)
All trust bearer-auth alone. Any operator can read or mutate any other operator's resources.
Affected operator-management handlers (in addition to A)
Beyond handleCreateOperatorAPIKey (covered by A), internal/api/operators.go is missing admin gates on:
handleListOperators(line 66) — operator roster info disclosurehandleDisableOperator(line 79) — DoS / sabotagehandleEnableOperator(line 94) — re-enable disabled operatorshandleRevokeOperatorAPIKey(line 157) — invalidate any operator's API keyshandleListOperatorAPIKeys(line 173) — API-key metadata disclosure
handleCreateOperator (line 26) IS properly gated (actorIsAdmin at line 27).
NOT affected (verified)
internal/api/cas.go properly gates every CA endpoint via canAccessCA (calls at lines 70, 176, 216) and admin shortcuts at lines 39, 82. An earlier description draft mistakenly listed /api/v1/cas/{id}/rotate as affected — that endpoint is properly protected. CAs are not in this gap.
Impact
- Any non-admin operator → admin via one curl (A).
- Any non-admin operator → ownership of any victim's hosts with cert + identity transfer (B).
- Mass cross-tenant CRUD including firewall-rule mutation (C).
- Any operator → disable/enable other operators, revoke their API keys, enumerate the operator roster.
CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — 9.6.
Suggested fix
Shared helpers in a new internal/api/authz.go, mirroring the Web layer's loadAccessibleCA:
func (s *Server) requireAdmin(w http.ResponseWriter, r *http.Request) bool
func (s *Server) requireOperatorAccess(w http.ResponseWriter, r *http.Request, operatorID string) bool
func (s *Server) requireHostAccess(w http.ResponseWriter, r *http.Request, hostID string) (*models.Host, bool)
func (s *Server) requireNetworkAccess(w http.ResponseWriter, r *http.Request, networkID string) (*models.Network, bool)
Each loads the resource, resolves its CA via *.CAID, accepts if actorIsAdmin(ctx) OR actor owns the CA. Reject 403 forbidden; audit-log api.<resource>.forbidden with the reason.
The operator-management endpoints take requireAdmin instead (operator ownership doesn't map to CA ownership).
Apply at the top of every host-, network-, firewall-, mobile-bundle-touching API handler, plus the 5 operator endpoints listed above. The legacy config-key path retains admin (preserves backward compatibility); the broader legacy-fallback question is tracked separately as issue #121.
Test matrix
- admin → all operations permitted
- owning non-admin → operations on owned hosts/networks permitted
- non-owner non-admin → 403 + audit entry
- legacy config-key → preserved (admin)
- unauthenticated → existing 401 from middleware
Coordinated context
Subsumes public issue #119 (mobile-bundle authz). Issue #121 (actor.go:40 legacy-admin fallback) is a separate concern tracked independently.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/juev/nebula-mesh | all versions | 0.3.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/juev/nebula-mesh. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/juev/nebula-mesh to 0.3.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-598g-h2vc-h5vg is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-598g-h2vc-h5vg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-598g-h2vc-h5vg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-598g-h2vc-h5vg in your dependencies?
O3 detects GHSA-598g-h2vc-h5vg across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.