vm2 CVE-2026-92956

Requires that the host application runs attacker-controlled JavaScript inside a vm2 sandbox - but critically NO special or unsafe configuration is needed: a plain default new VM() is vulnerable (no NodeVM, no require permission, no host-object injection). The single hard precondition is that the host process runs on Node.js 26, because the escape depends on WebAssembly.compileStreaming/instantiateStreaming producing a raw host-realm Promise/error on that runtime; hosts on other Node versions are not affected. Affected vm2 versions are 3.10.1 through 3.11.6 (fixed in 3.11.7). The primary limiting factor is therefore Node.js 26 adoption, not any application misconfiguration.

This is a genuine top-priority issue, not a high-CVSS-but-low-real-risk one. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with full VC/VI/VA:H and subsequent-system SC/SI/SA:H = 10.0) is credible because the escape is reachable from a completely DEFAULT new VM() sandbox - no NodeVM, require permission, host-object injection, or unsafe configuration is required, which distinguishes it from most vm2 escape siblings that were config-gated. Within vm2's threat model (the entire product exists to run untrusted/attacker-supplied JavaScript), the attacker already legitimately controls the sandbox input, so the only remaining precondition is that the host runs on Node.js 26. No EPSS score, CISA KEV entry, or explicit weaponized POC was provided in the input, so exploitation status is 'no public exploit identified at time of analysis' - but this is a well-documented technique with a full write-up in the GHSA advisory, so working exploit code is trivially reconstructable. The one signal that tempers raw priority is the Node.js 26 requirement: environments still on Node 18/20/22 LTS are not affected, so real-world exposure tracks Node 26 adoption rather than being universal. Net: for any service running untrusted JS in vm2 on Node.js 26, treat as critical and patch to 3.11.7 immediately; vm2 is also deprecated/unmaintained, so migration to isolated-vm or a process/container boundary is the strategic fix.

An application uses vm2's default new VM() to evaluate untrusted user-submitted JavaScript (e.g., a code playground, template engine, or serverless function runner) on a Node.js 26 host. The attacker submits script that calls WebAssembly.compileStreaming/instantiateStreaming to obtain a raw host-realm rejected Promise, hijacks Symbol.species via Promise.prototype.finally to receive the raw host error object, then walks from the host error constructor to the host Function constructor to recover the real host process object - gaining host Node.js capabilities such as require('fs') and command execution. No public exploit is listed in the input, but the GHSA advisory documents the full technique, making reliable exploitation straightforward.