Critical vm2 NodeVM Flaw Lets Sandboxed Code Hijack Host TLS Trust (CVE-2026-92941)

What happened

A GitHub Security Advisory (GHSA-98xx-8mx4-x7cm) published today discloses a critical flaw in vm2 3.11.6, tracked as CVE-2026-92941 with a reported CVSS of 10.0 and a public PoC. According to the advisory, vm2's NodeVM exposes the host tls module as a read-only bridge when it is explicitly allowlisted. That read-only wrapper blocks ordinary property writes but does not stop native calls — specifically tls.setDefaultCACertificates() on Node.js 22.19.0+ (22.x line) and 24.5.0+ (24.x line) — from mutating process-wide trust state from inside the sandbox.

The advisory describes the exploit as needing only the tls and url builtins (no fs, process, child_process, or wildcard grant). URLSearchParams.getAll() from the host-allowed url module is used to produce a genuine host-realm array containing attacker-supplied CA PEM data, which satisfies vm2's native type-check when passed into tls.setDefaultCACertificates() — replacing the host's default CA list for all subsequent TLS clients that don't supply their own ca option.

Why it matters

This is a sandbox-escape-adjacent issue: the attacker doesn't get direct file or command execution, but gains control over the host process's TLS trust decisions. Per the advisory, that can let an attacker-controlled CA be trusted by the host, enabling interception or tampering with HTTPS traffic for configuration, webhook, update, identity, or package-retrieval requests — anywhere the attacker can later influence the destination, DNS, routing, or a proxy. Replacing the CA list also strips normal trust roots, which the advisory notes can break unrelated host TLS connections entirely. Any service that runs untrusted or third-party code inside a vm2 NodeVM with the tls builtin allowed should treat this as in-scope.

What defenders should watch for

• Inventory where vm2 is used to run untrusted code, and whether NodeVM instances allowlist the tls builtin (directly or via a wildcard/dangerous-builtin gap) — per the advisory, dns is already blocked for an analogous reason but tls currently is not.
• Hunt for unexpected calls to tls.setDefaultCACertificates(), or anomalous changes in accepted TLS certificates for outbound host HTTPS clients that don't pin their own ca option.
• Watch for outbound HTTPS connections from vm2-hosting processes that suddenly succeed against certificates that would previously fail verification, or for a spike in unrelated TLS failures (a side effect of the default trust store being overwritten).
• As an interim mitigation, avoid exposing the tls builtin to NodeVM sandboxes, pin explicit ca options on sensitive host HTTPS clients rather than relying on process defaults, and track vm2 for a patched release.

Developing intel

This is a same-day, high-signal advisory and details may evolve as vm2 maintainers and the community respond — there is no confirmed patch referenced in the advisory text provided here. This is not a CVE tied to a df00tech detection rule at this time; treat the guidance above as hunting direction, not a tested query. For full technical detail and the PoC, see the original GHSA advisory: GHSA-98xx-8mx4-x7cm.