vm2 CVE-2026-45411

Exploitation requires that the target application (a) embeds vm2 at version <= 3.11.2 and (b) evaluates attacker-controlled JavaScript inside a new VM().run(...) (or equivalent NodeVM) sandbox - i.e., the application's threat model already trusts vm2 to contain hostile code. No authentication to the host OS, no user interaction, and no special vm2 configuration are needed beyond the default sandbox; the exploit works against stock new VM() instances. Limiting factors: applications that do not pass untrusted input into vm2 (e.g., using vm2 only for first-party code) are not exploitable in practice, and applications that have already migrated off vm2 to isolated-vm, worker threads with proper isolation, or external sandboxes are unaffected. The exploit relies on V8's PromiseResolveThenableJob behaviour, so any Node.js version shipping a modern V8 (Node 14+) is a viable target.

Signals diverge: CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) and SSVC (exploitation=poc, automatable=yes, technical impact=total) both rate this critical, and a working PoC is published on GitHub Gist, yet EPSS is only 0.05% (17th percentile) and the CVE is not in CISA KEV. The CVSS AV:N/PR:N rating is technically accurate but somewhat misleading - exploitation presupposes that an application already accepts and evaluates untrusted JavaScript inside a vm2 sandbox, which is itself the threat model vm2 exists to address; for applications that do (server-side code playgrounds, plugin runtimes, expression evaluators, SSRF-proxying renderers), this is a direct path to full host RCE with no authentication or user interaction. The low EPSS likely reflects that vm2 has been deprecated by its maintainer for over a year due to repeated unfixable escapes, so the realistic exploited population is narrower than a generic 9.8 would suggest - but for any system still running vm2 to isolate untrusted code, this should be treated as a top-priority issue.

A SaaS application that uses vm2 to evaluate user-supplied JavaScript (e.g., custom transform rules, formula fields, plugin code, or a code-execution playground) accepts a payload that defines an async generator delegating via yield* to an iterator without a return method, then calls i.return(thenable) while triggering deep recursion to provoke a host-realm RangeError; the attacker uses binary search to locate the precise depth and pivots through e.constructor.constructor('return process')() to obtain Node's process and call child_process.execSync for arbitrary command execution. A complete working PoC is published in the GHSA advisory and as a GitHub Gist, so weaponisation effort is minimal.