CVE-2026-47210: 
JavaScript 脆弱性の分析と軽減

CVE-2026-47210 is a critical sandbox escape vulnerability in vm2, an open-source Node.js VM/sandbox library, titled "vm2 sandbox escape via JSPI-backed Promise .finally() species bypass." It affects all versions up to and including 3.11.3, and was first published by the maintainer on May 18, 2026, with the GitHub Advisory Database entry published May 29, 2026, and NVD publication on June 12, 2026. The vulnerability allows unauthenticated attackers to execute arbitrary code in the host process when untrusted code is run with async support on Node.js runtimes exposing WebAssembly JSPI (Node 24 with --experimental-wasm-jspi, or Node 26+ by default). It carries a CVSS v3.1 base score of 9.8 (Critical) (Github Advisory, GitHub Security Advisory).

The root cause is classified as CWE-913 (Improper Control of Dynamically-Managed Code Resources). On Node 26+, WebAssembly.promising() returns Promise objects whose [[Prototype]] chain points directly at the host realm's Promise.prototype without any bridge proxy interposition — bypassing vm2's sandbox-side globalPromise.prototype overrides, resetPromiseSpecies hardening, and bridge apply-trap callback wrapping. An attacker can install a custom constructor getter on such a JSPI-backed Promise (Object.defineProperty(p, 'constructor', { get(){ return F }})), then call p.finally(()=>{}), which reaches the host Promise.prototype.finally. V8's host-realm SpeciesConstructor reads the attacker-controlled class F, and when a host-realm TypeError is eventually dispatched through F's reject closure, e.constructor.constructor('return process')() evaluates in the host realm — yielding full access to the Node.js process object and child_process. A working PoC was included in the advisory and targets node:26-bookworm (GitHub Security Advisory, Patch Commit).

Successful exploitation results in complete compromise of the host process running vm2, with high impact to confidentiality, integrity, and availability. An unauthenticated attacker can execute arbitrary OS commands, read or write any files accessible to the host process, and steal secrets, tokens, credentials, and application data. Any service relying on vm2 as a security boundary — such as code execution platforms, plugin sandboxes, or multi-tenant JavaScript evaluation services — is fully compromised, with potential for lateral movement within the host environment (Github Advisory, GitHub Security Advisory).

1. Identify target: Locate applications using vm2 versions ≤ 3.11.3 running on Node.js 26+ (where WebAssembly JSPI is enabled by default) or Node.js 24 with --experimental-wasm-jspi.
2. Craft malicious WebAssembly module: Prepare a minimal WASM binary that imports a JS function wrapped with WebAssembly.Suspending, causing a host-realm TypeError during JSPI processing.
3. Instantiate and obtain JSPI-backed Promise: Inside the vm2 sandbox, call WebAssembly.instantiate(wasmBytes, {m:{f: new WebAssembly.Suspending(...)}}) and then WebAssembly.promising(r.instance.exports.run)() to obtain a Promise p whose [[Prototype]] is the host realm's Promise.prototype.
4. Install attacker-controlled species: Define a custom class F with a reject handler that executes e.constructor.constructor('return process')() to access the host process object. Set Object.defineProperty(F, Symbol.species, {get(){return F}}) and Object.defineProperty(p, 'constructor', {get(){return F}}).
5. Trigger the bypass via .finally(): Call p.finally(()=>{}). This reaches host Promise.prototype.finally, V8's SpeciesConstructor reads F, and the host-realm rejection is dispatched through F's reject closure with no bridge wrapping.
6. Execute arbitrary commands: Inside F's reject handler, use e.constructor.constructor('return process')().mainModule.require('child_process').execSync('...') to run arbitrary OS commands in the host process (GitHub Security Advisory, Patch Commit).

• Process: Unexpected child processes spawned by the Node.js process running vm2 (e.g., sh, bash, execSync calls to system utilities); unusual child_process module usage originating from sandboxed code execution contexts.
• File System: Unexpected files created or modified by the Node.js service account (e.g., a pwned file as demonstrated in the PoC); new scripts, cron jobs, or binaries written to writable directories accessible by the host process.
• Logs: Application logs showing WebAssembly instantiation (WebAssembly.instantiate, WebAssembly.promising, WebAssembly.Suspending) within sandboxed code execution; errors or stack traces referencing Promise.prototype.finally in unexpected host-realm contexts.
• Network: Outbound connections from the Node.js host process to unexpected external IPs or domains following sandboxed code execution, potentially indicating reverse shell or data exfiltration activity (GitHub Security Advisory).

The fix is available in vm2 version 3.11.4, which removes WebAssembly.promising and WebAssembly.Suspending from the sandbox at bootstrap (mirroring the existing WebAssembly.JSTag removal), preventing JSPI-backed Promises from being created within the sandbox. Upgrading to v3.11.4 is the recommended remediation. As interim workarounds: disable async support and WebAssembly JSPI if not required by the application; avoid running vm2 on Node.js 26+ (or Node 24 with --experimental-wasm-jspi) until patched; and avoid using vm2 as a security boundary in high-risk environments. The patch is typeof-guarded and is a no-op on older Node versions where JSPI constants do not exist (vm2 Release v3.11.4, Patch Commit).

The vulnerability was covered by Heise Online, which reported on four critical security gaps with maximum ratings closed in vm2, highlighting the severity of the sandbox escape class (Heise Online). Security news outlet SecurityOnline.info also covered the vm2 sandbox escape vulnerabilities in the context of the broader v3.11.4 patch release (SecurityOnline). BeyondMachines noted the critical sandbox escapes enabling remote code execution (BeyondMachines). Community reaction has focused on the sophistication of the JSPI/Promise species bypass technique and the importance of treating vm2 as an untrusted execution environment rather than a hard security boundary.