PT-2026-48603 · Go · Github.Com/Juev/Nebula-Mesh

Published

2026-06-10

·

Updated

2026-06-10

·

CVE-2026-48025

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
internal/pki/resolver.go:36-64 constructs a CAManager with the plaintext ed25519.PrivateKey after unwrapping via the master key; internal/pki/ca.go:13-16 stores it. Callers at internal/api/enroll.go:116, internal/api/updates.go:297, and internal/api/mobile bundle.go:40 use the manager for one Sign() and drop the reference on function return — but the underlying slice contents are not wiped before release.
The keystore package's contract (internal/keystore/keystore.go doc: "Callers MUST zeroise the returned plaintext DEK as soon as it is no longer needed") is not met by the CAManager consumer. Decrypted CA private keys persist in process heap until Go's GC scavenges the underlying slice — minutes to hours under load, indefinitely on idle servers.

Affected

All released versions up to v0.3.6.

Threat model

Memory-read access: core dump, ptrace, kernel swap to disk, container/VM snapshot, OOM-debug bundle, side-channel via shared cache lines. Not a remote-network vulnerability, but defeats the master-key + envelope-encryption design's promise of "private key never lingers".

Suggested fix

Add a Wipe() method on CAManager:
// internal/pki/ca.go
func (m *CAManager) Wipe() {
  if m == nil {
    return
  }
  keystore.Zeroize(m.caKey)
}
At each call site (enroll.go:116, updates.go:297, mobile bundle.go:40, and any new caller), defer caMgr.Wipe() immediately after the Resolve() call. Pattern mirrors the existing defer keystore.Zeroize(dek) discipline in the keystore package.
Optional follow-up: wrap m.Sign() to zeroize after each call, removing the contract on callers — but the defer pattern is sufficient as a minimum.

Weakness Enumeration

CWE-244

Related Identifiers

CVE-2026-48025
GHSA-8H84-FHQQ-Q58V

Affected Products

Github.Com/Juev/Nebula-Mesh