vm2 EUVD-2026-81606

Exploitation requires the host application to run untrusted or attacker-controlled JavaScript inside vm2's NodeVM, AND to configure a wildcard require policy whose deny entry uses a node:-prefixed builtin specifier (e.g. new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })). Under that exact configuration the deny fails and sandboxed code reaches host child_process via require('child_process') or require('node:child_process'), yielding execSync/spawn. Limiting factors: vm2 must be used as a security boundary for untrusted code (PR:L - attacker must be able to run code in the sandbox); a correctly formed deny entry ('-child_process'), a non-wildcard allow-list, or not exposing child_process at all avoids the flaw; and the affected versions are through 3.11.6 (fixed 3.11.7). No end-user interaction is required.

This is a genuine high-priority sandbox-escape leading to host command execution, but its real-world risk is strongly conditioned on how vm2 is deployed. The vendor CVSS 4.0 score of 9.4 is credible for the vm2 threat model (an application that deliberately runs untrusted/attacker JavaScript inside NodeVM): PR:L reflects that the attacker need only be able to execute code in the sandbox, and VC:H/VI:H/VA:H plus subsequent-system SC:H/SI:H/SA:H correctly capture that escaping the sandbox compromises the host process. My independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, ~9.9) agrees on the severity of the impact given the preconditions. The critical qualifier is that this is a DENY-LIST BYPASS: it only bites deployments that (a) run untrusted code in NodeVM and (b) use a wildcard require policy while attempting to block a builtin using a node:-prefixed negative entry such as '-node:child_process'. A correctly written deny entry ('-child_process') or a non-wildcard allow-list is not affected. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so there is no evidence of active exploitation - exploitation status is 'no public exploit identified at time of analysis'. Note also that vm2 has been formally deprecated by its author (who recommends migrating off it entirely), which both raises baseline risk for anyone still using it as a security boundary and limits the population of exploitable, up-to-date deployments. Net: treat as high-priority for the specific population running untrusted code in vm2 with this policy pattern; lower practical urgency for everyone else.

An application uses NodeVM to run user-submitted JavaScript and tries to lock it down with a wildcard require policy like { builtin: ['*', '-node:child_process'] }, believing child_process is blocked. Because the deny entry is matched by exact string against the canonical name 'child_process' while require() strips the 'node:' prefix, the untrusted code simply calls require('child_process').execSync('...') and obtains full host command-execution. No public exploit code is referenced, but the technique is trivial to reproduce from the advisory description.