VM2 Has a WASM Sandbox Escape
Date: 2026-05
Affected: npm/vm2
Attack vector: sandbox-escape
Category: vulnerability-disclosure
Severity: Critical
CVE: CVE-2026-26956
CWE: CWE-693
CWE-94
CVSS: 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

## Summary Full sandbox escape with arbitrary code execution. Attacker code inside `VM.run()` obtains host process object and runs host commands with zero host cooperation. ## Details **Confirmed on:** vm2 3.10.4, Node.js v25.6.1 (x64 Linux) **Trigger:** Attacker-controlled code passed to `VM.run()` **Requires:** Node.js version with WebAssembly exception handling + JSTag support (tested on v25.6.1) vm2's sandbox security relies on two JavaScript-level mechanisms: (1) a code transformer that injects `handleException()` into JS `catch` clauses to wrap host-realm errors, and (2) bridge Proxies that wrap cross-context objects. Both operate entirely within JavaScript. WebAssembly's `try_table` instruction with a `JSTag` catch handler catches JavaScript exceptions at V8's C++ level — below JavaScript entirely. When an imported JS function throws a TypeError produced by Symbol-to-string coercion during stack formatting (`e.name = Symbol(); e.stack`), the WASM `try_table` catches it as an opaque `externref` and returns it as a normal function return value. This WASM exception-handling-to-return-value path is not sanitized by vm2 — the host-realm TypeError reaches attacker code unsanitized. Its constructor chain (`hostError.constructor.constructor`) resolves to a Function that returns the host process object, allowing for reflection outside of the vm2 context, leading to code execution. ## PoC ```js const { VM } = require("vm2"); console.log("vm2:", require("vm2/package.json")


Mitigations:

Architectural layers (MAESTRO):