GHSA-7hp6-g3pq-3pc3
Fix: forgekeep/nebula-mesh@c1506f7GHSA-7hp6-g3pq-3pc3 is a Code Injection vulnerability in github.com/juev/nebula-mesh. O3 Security confirms whether GHSA-7hp6-g3pq-3pc3 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
nebula-mesh: Host advanced overrides allow YAML injection into agent config.yml
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-7hp6-g3pq-3pc3.
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.
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
internal/configgen/generator.go:86,108,119 interpolates the operator-supplied ListenHost and TunDevice fields raw into a text/template that produces the agent's config.yml. internal/web/advanced.go:20-35 accepts both with only strings.TrimSpace — no character or shape validation.
Exploit
An operator (or attacker with any operator key, given the cross-tenant CRUD advisory) sets adv_tun_device to:
nebula0
lighthouse:
am_lighthouse: true
hosts: ["10.0.0.1"]
#
The agent fetches the rendered config on its next signed poll. On config reload, it loads the injected YAML keys: the host self-promotes to lighthouse, attracts mesh traffic, or sets am_relay: true to be selected as a relay. The ListenHost field has the same shape.
Affected
All released versions prior to v0.3.2.
Threat model
- Today: operator can compromise their own host's config (trivially allowed if they own the host, but they can also set lighthouse/relay flags that the operator-create form does NOT expose — privilege uplift within their own tenant).
- Combined with the critical /api/v1 authz advisory: any operator key can mutate ANOTHER tenant's host overrides and inject YAML there.
- Post-fix of the authz advisory: still relevant — the agent unconditionally trusts whatever config the server hands it, so any future operator-impersonation bug re-amplifies this.
Suggested fix
Two options, either acceptable:
-
Input validation in
parseAdvancedFromForm(internal/web/advanced.go):ListenHost: regex^[A-Za-z0-9.:\[\]_-]+$(IPv4/IPv6/hostname)TunDevice: regex^[A-Za-z0-9_-]{1,15}$(Linux IFNAMSIZ caps at 15) Reject invalid input with a form-level error; do not write to the host row.
-
Safer marshalling: switch
configgen/generator.goto marshal a typed Go struct viagopkg.in/yaml.v3(which escapes correctly) instead oftext/templatestring-concat. Larger change, but eliminates this entire injection class.
Option 2 is preferable long-term. Option 1 is the quick fix.
The unsafe_routes advanced field is already netip.Parse{Prefix,Addr}-validated at enroll.go:226-233 — apply the same validation discipline to the other advanced fields.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/juev/nebula-mesh | all versions | 0.3.2 |
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.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7hp6-g3pq-3pc3 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-7hp6-g3pq-3pc3 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-7hp6-g3pq-3pc3. 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-7hp6-g3pq-3pc3 in your dependencies?
O3 detects GHSA-7hp6-g3pq-3pc3 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.