vm2 Sandbox Escape via Nullish 'this' Receiver in Bridge apply Trap (CVE-2026-93603)

Technical Analysis

The vulnerability exists in vm2's bridge.js apply trap, which fails to correctly handle calls to host-provided non-strict (sloppy-mode) functions made without an explicit receiver (e.g., fn(), fn.call(), fn.apply(undefined), Reflect.apply(fn, undefined, []), or fn.bind()()). When sandboxed code invokes such a function, V8 automatically substitutes the host realm's global object as 'this', and vm2 mistakenly wraps and returns this object as a proxy back to the sandbox. This grants sandboxed script direct access to the host's global scope, enabling retrieval of the Node.js 'process' object and execution of arbitrary system commands via methods such as process.getBuiltinModule('child_process').execSync. Exploitation only requires the embedding application to expose at least one non-strict host function to the sandbox; strict-mode and ES module functions are not vulnerable, giving defenders a partial mitigation path. AI agent frameworks, RAG pipelines, and LLM tool-execution environments that use vm2 to sandbox generated code, plugin execution, or untrusted user scripts are directly exposed — a malicious or manipulated agent output (e.g., LLM-generated code executed in a vm2 sandbox) could achieve full host compromise, including exfiltration of API keys, model credentials, and lateral movement into agent orchestration infrastructure.

Affected Systems

vm2 npm package versions through 3.12.0 (fixed in 3.12.1); any Node.js application, service, CI/CD pipeline, serverless function, or AI agent/tool-execution framework that uses vm2 to sandbox untrusted or LLM-generated JavaScript code and exposes at least one non-strict (sloppy-mode) host function to the sandbox.

Indicators of Compromise

• N/A - logic vulnerability in library code, no known malware hashes or network IOCs
• Affected package: vm2 (npm)
• Vulnerable file: lib/bridge.js
• Exploitation pattern: sandboxed calls such as fn(), fn.call(), fn.apply(undefined), Reflect.apply(fn, undefined, []), fn.bind()()
• Suspicious runtime indicator: unexpected access to process.getBuiltinModule('child_process') or execSync from within a supposed sandbox context

Remediation Steps

1. 1

   Upgrade vm2

   Immediately update vm2 to version 3.12.1 or later, which fixes the nullish 'this' receiver handling in the bridge apply trap.

2. 2

   Audit exposed host functions

   Review all host functions exposed to vm2 sandboxes and convert non-strict (sloppy-mode) functions to strict mode or ES modules where possible to reduce exposure even if upgrade is delayed.

3. 3

   Migrate away from vm2

   Given vm2's history of repeated sandbox-escape vulnerabilities and lack of active maintenance, evaluate migration to actively maintained isolation solutions such as isolated-vm, V8 isolates, or OS-level sandboxing (containers, gVisor, Firecracker).

4. 4

   Restrict host process privileges

   Run sandboxed code execution processes with least-privilege service accounts, no direct filesystem/network access, and without sensitive environment variables such as API keys or credentials used by AI agents.

5. 5

   Audit AI agent and code-execution pipelines

   Specifically review any LLM agent, RAG, or plugin execution framework that relies on vm2 for sandboxing generated or user-submitted code, and apply the patch or isolate these components in separate hardened environments.

6. 6

   Monitor for exploitation indicators

   Deploy runtime monitoring for unexpected child_process spawning, access to global process objects, or anomalous outbound connections originating from sandboxed execution environments.