vm2 Sandbox Escape Vulnerabilities

vm2 npm package versions 3.9.6 through 3.10.5 allow sandbox escape through prototype pollution of host-realm intrinsic objects. Attackers execute arbitrary code by leveraging flawed proxy bridge implementation that writes sandbox mutations directly to shared host Object.prototype, Array.prototype, and Function.prototype instead of isolating changes to the sandbox realm. This vulnerability was patched in vm2 v3.11.0 as part of a coordinated release addressing 13 security advisories. Publicly available exploit code exists with minimal attack complexity (CVSS AC:L) requiring no authentication or user interaction (AV:N/PR:N/UI:N).

Remote code execution in vm2 Node.js sandbox library (versions ≤3.10.5) allows attackers to escape isolation and execute arbitrary system commands by exploiting incomplete host Object protections. Attackers leverage JavaScript prototype chain manipulation to obtain host-context symbols, enabling injection of malicious code into Node.js inspection routines. Publicly available exploit code exists with working proof-of-concept demonstrating command execution via child_process. CVSS 10.0 (Critical) with network attack vector and no authentication required. Fixed in vm2 3.11.0, part of coordinated release addressing 13 sandbox-escape vulnerabilities.

Prototype chain manipulation in vm2 Node.js sandbox library enables complete sandbox escape and remote code execution via util.inspect handler leakage. Attackers can exploit BaseHandler.getPrototypeOf through crafted objects to access host process primitives and execute arbitrary system commands. Public exploit code exists (vendor-published PoC demonstrates child_process.execSync execution). Fixed in vm2 version 3.11.0 alongside 12 other critical sandbox escape vulnerabilities in coordinated security release.

vm2's NodeVM sandbox escape allows remote code execution when applications use the common `builtin: ['*', '-child_process']` configuration pattern. An attacker with the ability to submit code to the sandbox can bypass the builtin allowlist by requiring the `module` builtin, then using `Module._load()` to load explicitly excluded modules like `child_process` in the host context. This directly leads to arbitrary command execution on the host system. The vulnerability affects vm2 version 3.10.5, with a vendor-released patch available in version 3.11.0. CVSS score of 9.9 reflects critical severity with network attack vector, low complexity, and scope change from sandbox to host. No public exploit code or active exploitation evidence identified at time of analysis.

vm2 NodeVM with nesting:true silently overrides require:false, granting sandbox code unconditional access to require('vm2') and enabling remote code execution on the host via nested NodeVM construction. Applications running untrusted code in a NodeVM configured with {nesting:true, require:false} are fully compromised — attackers can execute arbitrary OS commands as the host process user. Publicly available exploit code exists (proof-of-concept demonstrated command execution via child_process). CVSS 9.1 indicates high privileges required (PR:H), meaning the host must explicitly enable nesting:true, but the severity reflects scope change (S:C) when this non-default configuration is present. Vendor-released patch in vm2 3.11.1 converts contradictory configuration into a runtime error at NodeVM construction time, preventing silent sandbox escape.

Remote unauthenticated attackers can crash Node.js processes running vm2 <= 3.10.5 by triggering an unhandled Promise rejection that terminates the host application. The vulnerability exploits an incomplete fix for CVE-2026-22709 - while previous patches sanitized `.then()` and `.catch()` callback chains, they failed to intercept unhandled rejections originating from Promise constructor executors. Publicly available exploit code exists (GitHub advisory GHSA-hw58-p9xv-2mjh). The attack requires minimal resources (150-byte HTTP request) but achieves high impact by crashing entire server processes serving all concurrent users, with demonstrated persistent DoS despite container orchestration restart policies.

Remote code execution in vm2 NodeVM sandbox allows untrusted code to bypass `require.root` path restrictions and load arbitrary modules from outside the allowed root directory via symlink traversal. The vulnerability exploits a check/use path discrepancy: path validation uses `path.resolve()` which does not dereference symlinks, but module loading uses Node's native `require()` which does follow symlinks. Attackers with ability to submit code to the sandbox (the intended use case) can load host-realm modules like vm2 itself or child_process to achieve arbitrary command execution. Confirmed actively exploited (CISA KEV) with publicly available exploit code. Common in production environments using pnpm (where ALL node_modules are symlinks), npm workspaces, or npm link. Vendor-released patch: vm2 3.11.0.

Denial-of-service in vm2 Node.js sandbox allows unauthenticated remote attackers to crash host processes via unbounded Buffer.alloc() calls. The vm2 library's timeout mechanism cannot interrupt synchronous C++ native calls, enabling attackers to bypass configured timeout limits and exhaust host heap memory with a single HTTP request. Version 3.11.0 patches this flaw by introducing bufferAllocLimit controls. Publicly available exploit code exists (GHSA-6785-pvv7-mvg7 includes working POC), and while EPSS data is unavailable and the vulnerability is not listed in CISA KEV, the vendor-confirmed POC demonstrates reliable exploitation against default configurations.

Sandboxed JavaScript running inside vm2 3.10.5 and earlier can obtain a raw reference to a host object when the embedding application hands a host-side Promise that resolves to a host object into the sandbox: the fulfillment wrapper calls ensureThis() instead of the stronger cross-realm conversion path, and when no prototype mapping exists ensureThis() returns the original host object unchanged. The result is a boundary violation that lets unauthenticated sandbox code confirm host object identity through a host-side WeakMap/WeakSet oracle and write through to the resolved host object's state, as demonstrated by public proof-of-concept code published with the vendor advisory (SSVC exploitation status: poc). Exposure is conditional, not default: only applications that explicitly expose such host Promises into the sandbox and whose resolved objects lack a prototype mapping are affected, and demonstrated impact is limited to the objects reachable through those Promises (CVSS 7.2, scope changed, low confidentiality and integrity impact). EPSS is 0.04% (11th percentile) and there is no CISA KEV listing; the vendor fixed the flaw in vm2 3.11.0.

Security control bypass in vm2 sandbox allows direct access to internal VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL variable by exploiting a performance optimization in the code transformer that skips AST analysis when code lacks catch, import, or async keywords. Affected versions <= 3.10.5 expose internal security functions (handleException, wrapWith, import) and enable with-statement scope manipulation, creating a latent attack surface for future sandbox escapes. All applications using vm2 to execute untrusted code are affected; exploitation requires no special configuration or authentication.

Information disclosure in vm2 allows sandboxed code to extract host absolute file paths, library locations, and internal function names via stack trace inspection, enabling attackers to map the host server's directory structure and architecture without authentication or user interaction. The vulnerability affects all versions up to 3.10.5 and is triggered through either default error.stack formatting or custom Error.prepareStackTrace handlers; vendor-released patch available in version 3.11.0.