vm2 NodeVM Sandbox Escape via node:test Builtin Passthrough (CVE-2026-92948, CVSS 9.9)

A newly published GitHub Security Advisory (GHSA-qhwx-74w5-xhxq) discloses a sandbox escape in vm2's NodeVM, tracked as CVE-2026-92948 with a reported CVSS of 9.9 and a public proof-of-concept.

What happened

According to the advisory, on Node.js 24 and newer, embedders who explicitly allowlist the node:test builtin (via require: { builtin: ['node:test'] }) can have that module exposed to sandboxed code in an exploitable way. Sandbox code can reach it through the doubled-prefix path require('node:node:test'), which vm2's prefix-stripping logic normalizes back to the allowlisted node:test entry. From there, calling the host node:test.run() API with attacker-controlled execArgv — for example --eval=<JavaScript> — spawns a separate, unrestricted host Node process that executes arbitrary JavaScript outside the sandbox boundary entirely.

The advisory states affected versions are vm2 >=3.9.6, <=3.11.5, reproduced on Node.js v24.18.0, with the exploit path not present on Node.js 22 because module.builtinModules does not expose the scheme-only node:test entry on that runtime. [email protected] reportedly blocks the doubled-prefix require, while 3.9.6 onward permits it.

Why it matters

vm2 is widely used to run untrusted or semi-trusted JavaScript in a restricted context — plugin systems, CI/build tooling, bots, and multi-tenant code-execution services are common consumers. Per the advisory, successful exploitation runs arbitrary JavaScript under the embedder's OS identity, with the host's filesystem, environment, network, and process-execution permissions — a full confidentiality, integrity, and availability compromise of the hosting service. The precondition is specific: the embedder must explicitly allowlist the node:test builtin for the sandbox, so not every vm2 deployment is exposed, but any that do enable it on Node.js 24+ should treat this as critical.

What defenders should watch for / do now

• Audit any service using vm2's NodeVM to determine whether the require.builtin configuration includes node:test (explicitly or via a wildcard), and on which Node.js major version it runs.
• Where node:test is allowlisted and not strictly required by sandboxed code, remove it from the builtin list as an immediate mitigation.
• Per the advisory's suggested remediation, treat the test builtin family as dangerous (comparable to existing DANGEROUS_BUILTINS entries) until an upstream fix lands, and apply it via a patched build or override if you cannot wait for a release.
• For hunting/monitoring, watch for child Node.js processes spawned from a sandboxing/embedder process with unexpected --eval, --require, or --import flags in their command line — the advisory specifically calls out these flags as the mechanism for host code execution via execArgv passthrough.
• Review logs/telemetry for sandboxed-code requires of node:node:test or other doubled-prefix builtin paths, since that is the specific normalization quirk enabling the bypass per the writeup.
• Given vm2 itself has seen prior sandbox-escape history, organizations relying on it for untrusted-code execution should also weigh longer-term migration to actively maintained isolation primitives (e.g., separate OS processes/containers, or newer sandboxing libraries) rather than relying solely on in-process JS sandboxing.

Developing intel

This is a same-day advisory and the information above reflects only what has been publicly disclosed so far; vendor/maintainer response, an official patched release, and broader exploitation reporting may still be forthcoming. We will track this item for updates. Full technical details, the proof-of-concept, and the maintainer's advisory are available at the original source: GHSA-qhwx-74w5-xhxq.