vm2 EUVD-2026-81597

Requires ALL of: (1) the target runs vm2 NodeVM executing untrusted attacker-supplied JavaScript (the vm2 threat model - this is the 'authentication' PR:L represents); (2) the Node.js runtime is version 24 or newer, since only there does module.builtinModules expose the scheme-only 'node:test' key; and (3) the embedder has explicitly enabled the non-default configuration require:{builtin:['node:test']}, which is not a default allowlist. Given those, no user interaction and no further authentication are needed. Limiting factors that reduce realistic exposure: older Node versions are not vulnerable, and applications that do not explicitly allow node:test (the vast majority) are unaffected regardless of Node version.

This is a genuine full sandbox-escape to arbitrary code execution on the host Node process, but its real-world reachability is meaningfully constrained by two hard prerequisites, so it should not be treated as a drop-everything remote-RCE. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N with VC:H/VI:H/VA:H and subsequent-system SC:H/SI:H/SA:H = 9.4) reflects the fact that once triggered the attacker fully compromises the host outside the sandbox. However, the description makes clear two limiting gates the vector does not capture: (1) the runtime must be Node.js 24 or newer (older Node does not expose the scheme-only node:test key), and (2) the embedder must explicitly opt into an unusual, non-default configuration that allowlists node:test (require:{builtin:['node:test']}). The PR:L in the vendor vector is best read as the vm2 threat model itself - the attacker is the untrusted JavaScript vm2 is deliberately running - rather than a network authentication credential. No EPSS score, no CISA KEV listing, and no explicitly flagged public exploit are present in the supplied data (a working advisory write-up likely exists in GHSA-qhwx-74w5-xhxq but is not confirmed as weaponized). Net: technically critical impact, real priority for anyone running the exact affected stack, but gated enough (Node 24+ AND a deliberate node:test allowlist AND already accepting untrusted code) that it is not indiscriminately mass-exploitable. Note also that the '3.11.7 fixed' claim sits oddly against the real-world vm2 history (project deprecated in 2023, last widely-known release ~3.9.19) - worth verifying versioning independently.

An application uses vm2's NodeVM on Node.js 24+ to run untrusted user-supplied JavaScript and, unusually, allows the node:test builtin via require:{builtin:['node:test']}. Sandboxed code calls require('node:node:test'), whose double 'node:' prefix is stripped once and resolves to the host node:test proxy; it then invokes node:test.run() with attacker-controlled execArgv containing --eval=<JavaScript>, which the host spawns in a fresh, unrestricted Node process, executing arbitrary code fully outside the sandbox. No public exploit is confirmed in the provided data, though a technical advisory (GHSA-qhwx-74w5-xhxq) likely documents the primitive.