CVE-2026-92956

vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default new VM() sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host process object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.

vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default new VM() sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host process object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-wjwh-qqvp-g4p4. This link is maintained to preserve external references.

Original Description

vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default new VM() sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host process object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.

Summary

There is a sandbox escape in vm2 3.11.5 / current HEAD when it is used on Node.js 26. The issue is reachable from a default new VM() sandbox. No NodeVM, require permission, host object injection, or intentionally unsafe configuration is required.

The escape is a patch-bypass of the same security invariant addressed by GHSA-6j2x-vhqr-qr7q. The earlier fix removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending, because those APIs exposed a Promise path whose host-realm Promise.prototype was not intercepted by vm2's Promise hardening or bridge layer.

The same unsafe class remains reachable through WebAssembly.compileStreaming and WebAssembly.instantiateStreaming. On Node 26, these streaming APIs can produce a raw host-realm Promise path that rejects with a host-realm error. By controlling Symbol.species through Promise.prototype.finally, sandbox code can receive that raw host error object, walk from the host error constructor to the host Function constructor, and recover the real host process object.

The proof of concept demonstrates this by first showing that direct access to process, require, and constructor-based escapes are blocked in the same default VM. It then reaches the host process, verifies that the recovered pid matches the parent Node process, and writes a harmless marker file through host fs.

Impact

This is a sandbox escape. In applications that expose vm2 execution to attacker-controlled JavaScript, the issue can become host code execution in the context of the Node.js process running the sandbox.

This is not remote code execution by default. The remote aspect depends on the embedding application. The accurate framing is:

An attacker who can supply JavaScript to a vm2 VM sandbox on Node 26 can break out of the vm2 boundary and obtain host Node.js capabilities.

This matters for services that use vm2 as a security boundary for untrusted JavaScript, including plugin runners, workflow engines, automation platforms, online code runners, browser-automation sandboxes, and AI-agent or user-script execution environments.

The PoC only writes a marker file under the OS temporary directory. That marker is intentionally harmless. The security impact is not the marker itself; the security impact is that sandbox-controlled code obtains the real host process and host modules after the control case proves those capabilities are normally blocked.

Tested versions and configuration

Tested vm2 3.11.5 at commit 7a1f5100b96f48d34e0fe104ab37c0acc5944f92.

The escape reproduced on Node.js 26.2.0. I also tested the same PoC on Node.js 20.20.2, 22.22.3, and 24.15.0; those versions did not recover the host process through this path.

The test case uses the default VM boundary only:

const { VM } = require('./lib/main');
const vm = new VM({ timeout: 8000 });

vm.run(attackerControlledJavaScript);

No NodeVM was used. The sandbox was not given require, process, fs, child_process, host callbacks, or host objects. The PoC only controls the JavaScript string passed to vm.run().

The version dependency appears to be in the final delivery step: on Node 26 the host-realm rejection from WebAssembly.compileStreaming reaches the attacker-controlled finally/Symbol.species capability, while the same path did not become exploitable in my Node 20/22/24 tests. I would still treat the fix as version-independent: sandbox code should not be able to receive this raw host-Promise path from the WebAssembly streaming APIs at all.

Root cause

The security boundary relies on vm2 keeping Promise objects that are reachable from sandbox code in one of two safe shapes:

1. Sandbox-realm Promise. The Promise uses the sandbox's Promise prototype chain, so vm2's Promise hardening can pin species and sanitize callbacks.
2. Bridge-proxied host Promise. The Promise is a host object crossing through vm2's membrane, so bridge…

vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default new VM() sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host process object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.

vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default new VM() sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host process object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.