EUVD-2026-71717
GHSA-2p2f-px33-4vv5
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Key recovery requires local process-memory read access; scope changes because a compromised CA key enables certificate forgery across the entire mesh.
Primary rating from Vendor (https://github.com/forgekeep/nebula-mesh).
CVSS VectorVendor: https://github.com/forgekeep/nebula-mesh
Lifecycle Timeline
8DescriptionCVE.org
Impact
The web handler renderMobileBundle (internal/web/handlers.go:1325) passes the real *pki.CAResolver directly into mobilebundle.Build. Inside Build (internal/mobilebundle/builder.go:54), resolver.LoadByID decrypts the CA's ed25519 private key into a *pki.CAManager, but Build never calls CAManager.Wipe() on any return path (success or any of the error paths at lines 56, 62, 68, 80, 86, 92, 98, 102, 109, 118, 150).
As a result, when a mobile-bundle request goes through the web UI and Build returns - especially on error (missing network, invalid prefix, DB error, signing failure) - the plaintext CA private key remains on the Go heap, unwiped, until garbage collection. An attacker able to read process memory (core dump, swap, memory-scraping) can recover the CA signing key, which would allow minting arbitrary host certificates for the mesh.
The API handler (internal/api/mobile_bundle.go:74) already does this correctly: it loads the CAManager, defer caMgr.Wipe(), and wraps it in caManagerResolver. Only the web path is affected.
This is the same key-zeroization class previously addressed in GHSA-8h84-fhqq-q58v.
Patches
Add defer caMgr.Wipe() inside mobilebundle.Build immediately after the LoadByID call so every caller (web and API) is protected on all return paths. Ensure CAManager.Wipe() is idempotent, since the API handler also wipes the same manager.
Workarounds
None at the configuration level; requires a code fix.
Resources
internal/web/handlers.go:1325internal/mobilebundle/builder.go:54internal/api/mobile_bundle.go:74(correct reference implementation)- Prior related advisory: GHSA-8h84-fhqq-q58v
AnalysisAI
nebula-mesh's web mobile-bundle handler leaves the decrypted ed25519 CA private key resident on the Go heap because mobilebundle.Build never calls CAManager.Wipe() on any of its eleven return paths - success or error - allowing the 64-byte signing key to persist in process memory until garbage collection. An authenticated actor who triggers the renderMobileBundle web handler combined with any capability to read process memory (core dump, swap file, or live memory scraping) can recover the CA signing key and mint arbitrary host certificates trusted by every node in the nebula mesh. No public exploit has been identified at time of analysis; the API handler performs correct zeroization via defer caMgr.Wipe() and is unaffected.
Technical ContextAI
nebula-mesh (pkg:go/github.com/forgekeep/nebula-mesh) is a Go overlay-network daemon whose CA subsystem wraps ed25519 signing keys inside a pki.CAManager struct with a Wipe() method that zeroes the in-memory key buffer on demand. CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer) governs this class: cryptographic material decrypted into RAM must be explicitly overwritten after use, because Go's garbage collector does not zero freed memory on reclaim and the key may remain readable for an indeterminate period. In internal/mobilebundle/builder.go:54, resolver.LoadByID decrypts the CA private key into a *pki.CAManager but the function exits on eleven distinct paths - lines 56, 62, 68, 80, 86, 92, 98, 102, 109, 118, and 150 - without invoking Wipe(). The sibling API handler at internal/api/mobile_bundle.go:74 demonstrates the correct defensive pattern and serves as the reference implementation cited in the advisory. The prior advisory GHSA-8h84-fhqq-q58v addressed the same zeroization deficiency in a different handler, confirming this is a recurring architectural gap.
RemediationAI
Upgrade nebula-mesh to v0.3.8, which introduces defer caMgr.Wipe() immediately after the LoadByID call in mobilebundle.Build, protecting both the web and API callers on every return path. The specific patch is commit 1f1ab9aa8472239763d967e3d50a3cd53a1a79b9 and the release tag is at https://github.com/forgekeep/nebula-mesh/releases/tag/v0.3.8. The vendor advisory explicitly states no configuration-level workaround exists and a code fix is required. For operators unable to patch immediately, restrict web UI access to trusted administrators and firewall the web handler port to reduce the attack surface for triggering key decryption; additionally, ensure the daemon process runs in a memory-isolated environment (dedicated VM, seccomp/AppArmor preventing ptrace, encrypted swap) to impede heap-scraping. After patching, audit for any pre-existing core dumps or swap artifacts that may contain residual key material, as those should be securely deleted.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today