vm2 CVE-2026-93605

Exploitation requires the host application to have already run untrusted/attacker-controlled JavaScript inside a vm2 NodeVM instance AND to have configured that instance with builtin:['*'] (wildcard builtin allowance) or an explicit child_process entry in the allowed builtins. Under those conditions the sandboxed code simply calls require('child_process') and executes host commands - no authentication or user interaction beyond code submission. The key LIMITING factor is that this is NOT a default configuration: applications that omit child_process from their builtins allowlist (or allow no builtins) are not exploitable via this path. Additionally, vm2 is deprecated, so affected deployments are those still embedding the library to sandbox untrusted code.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC/VI/VA/SC/SI/SA all High = 10.0) frames this as maximum-severity unauthenticated remote code execution, and mechanically a sandbox escape that yields arbitrary host command execution does warrant near-top scores. However, the raw 10.0 is conditional: the description explicitly states exploitation only works 'when NodeVM is configured with builtin:["*"] or explicit child_process allowance.' That is a non-default host-application configuration, so the AT:N (no attack requirement) choice in the vendor vector is arguably too generous - AT:P is more honest. No EPSS score, no CISA KEV listing, and no explicit POC flag are provided in the input, so there is no evidence of active exploitation; the signals available are limited to VulnCheck's advisory and the vendor GHSA. Net: this is a genuinely high-priority issue for any deployment that runs untrusted code in vm2 NodeVM with builtins enabled (the flaw is trivial once that config is present - child_process was simply left off the DANGEROUS_BUILTINS denylist), but it is NOT a blanket 'every vm2 user is remotely ownable' situation. vm2 is also deprecated by its author, which shifts remediation toward migration rather than patching. Prioritize based on whether your app actually allows child_process or wildcard builtins.

An application uses vm2 NodeVM to execute user-submitted JavaScript (e.g., an online code runner, serverless function evaluator, or plugin engine) and is configured with builtin:['*'] or an explicit child_process allowance. An attacker submits sandboxed code that calls require('child_process').execSync(...), which the DANGEROUS_BUILTINS denylist fails to block, executing arbitrary OS commands on the host. No public exploit was identified in the provided data, but the mechanism is documented in the VulnCheck and GHSA advisories and is trivial to reproduce.