vm2 sandbox escape via WebAssembly.compileStreaming Promise species bypass

Story map

Why it is Red

• CVSS 10.0 critical
• Public exploit or proof of concept referenced
• Remotely exploitable without logging in
• On your watchlist: npm

Affected packages

References

• https://github.com/advisories/GHSA-wjwh-qqvp-g4p4
• https://github.com/patriksimek/vm2/security/advisories/GHSA-wjwh-qqvp-g4p4
• https://nvd.nist.gov/vuln/detail/CVE-2026-92956
• https://github.com/patriksimek/vm2/commit/cb85599e4470afa308e7c807b5c6b3ec9bf58b18
• https://github.com/patriksimek/vm2/blob/415339f698f0d52d3c5ad358b12b79c8072d5b4b/lib/setup-sandbox.js#L510-L523
• https://github.com/patriksimek/vm2/releases/tag/v3.11.7
• https://www.vulncheck.com/advisories/vm2-3.10.1-through-3.11.6-sandbox-escape-via-webassembly-compilestreaming
• https://github.com/advisories/GHSA-wjwh-qqvp-g4p4

Original description

## 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: ```js 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 traps and callback sanitizers apply. `WebAssembly.compileStreaming` and `WebAssembly.instantiateStreaming` introduce a third shape: a raw host-realm Promise path that is directly reachable from sandbox code and is not bridge-proxied. This is the same class of object that made the JSPI issue dangerous. The exploitability depends on two facts being true at the same time: - the streaming WebAssembly API returns a Promise path whose relevant Promise machinery is host-realm rather than sandbox-realm; and - the rejection generated by passing an invalid streaming source is a host-realm `TypeError` from Node's WebAssembly streaming implementation. Once that host error is delivered to attacker-controlled code, the usual host-realm constructor walk becomes possible: ```js hostError.constructor.constructor('return process')() ``` That expression resolves through the host `Function` constructor, not the sandbox one, because the error object is host-realm. ## Exploit flow The exploit flow is small, but the realm boundary is the important part: 1. Sandbox code calls `WebAssembly.compileStreaming(0)`. 2. The argument is not a valid `Response` or Promise resolving to a `Response`, so the returned Promise rejects. 3. On Node 26, the rejection value is a host-realm error object. 4. The attacker installs a controlled `constructor` accessor on the returned Promise and provides a custom `Symbol.species` constructor. 5. Calling `p.finally(() => {})` reaches the species path used by `Promise.prototype.finally`. 6. `NewPromiseCapability(F)` invokes the attacker-controlled constructor `F` and exposes the result capability functions. 7. When the Promise rejects, the host-realm error is delivered to the attacker-controlled rejection path. 8. The attacker uses the host error's constructor chain to recover host `process`. 9. The PoC loads host `fs` through `process.mainModule.require('fs')` and writes a harmless marker file. `Promise.prototype.finally` is important because it is the r