CVE-2026-93603 in vm2
Summary
by MITRE • 09/18/2026
vm2 through 3.12.0 (fixed in 3.12.1) does not correctly handle a nullish `this` receiver in the apply trap of its bridge (lib/bridge.js): when sandboxed code calls a host-provided non-strict (sloppy-mode) function without a receiver — e.g. `fn()`, a detached method, `fn.call()`, `fn.apply(undefined)`, `Reflect.apply(fn, undefined, [])`, or `fn.bind()()` — the undefined receiver is passed straight through to the host call, and V8 substitutes the host realm's global object for `this`. vm2 then wraps and returns that object to the sandbox, giving sandboxed script a live proxy of the host global. This allows a complete sandbox escape: untrusted script can reach `process` and execute arbitrary code/commands on the host (for example via `process.getBuiltinModule('child_process').execSync`). Exploitation requires that the embedding application expose at least one non-strict host function to the sandbox; strict-mode and ES module host functions are not affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in vm2 versions through 3.12.0 represents a critical security flaw within the JavaScript virtual machine implementation, specifically affecting how the library handles context isolation during method invocation via its bridge mechanism. The core technical issue resides in lib/bridge.js, where the apply trap fails to correctly sanitize or replace a nullish this receiver when sandboxed code interacts with host-provided functions operating in non-strict mode. In standard JavaScript execution environments like V8, if a function defined in sloppy-mode is invoked without an explicit object context—such as through direct calls fn(), detached method invocations, fn.call(undefined), fn.apply(null), Reflect.apply(fn, null, []), or bound methods executed with undefined—the engine automatically substitutes the global object of the current realm for this. However, vm2’s bridge logic erroneously passes this undefined receiver directly to the host function without performing the necessary context isolation checks that are typically required when crossing sandbox boundaries.
This oversight results in a severe breach of the security boundary between the untrusted sandboxed environment and the trusted host application. Because V8 substitutes the global object for the missing receiver, vm2 inadvertently wraps this host realm's global object and returns it as a live proxy to the sandboxed script. This effectively grants the untrusted code direct access to the host’s global scope, which contains sensitive internal objects such as process in Node.js environments. The presence of these exposed globals allows an attacker to bypass all intended isolation mechanisms, leading to a complete sandbox escape where arbitrary code execution can be achieved on the underlying system.
The operational impact of this vulnerability is severe, enabling remote attackers or malicious scripts within the sandboxed context to access critical host APIs that should remain inaccessible. Specifically, by obtaining a reference to the global object, an attacker can retrieve built-in modules such as child_process and execute arbitrary operating system commands via functions like execSync. This transforms what might appear to be a contained execution environment into a full remote code execution vector against the hosting application or server infrastructure. The severity is compounded by the fact that this escape mechanism relies on standard JavaScript behaviors, making it difficult for developers to detect without deep understanding of vm2’s internal bridge implementation and V8’s context handling rules.
Mitigation strategies must focus primarily on upgrading the affected software component immediately. Users running versions 3.12.0 or earlier should upgrade to version 3.12.1 or later, where this logic error in the apply trap has been corrected to properly handle nullish receivers and prevent the leakage of host globals into the sandboxed context. For applications that cannot update immediately due to dependency constraints, a temporary workaround involves ensuring that all host functions exposed to the vm2 sandbox are defined as strict-mode functions or ES modules. Since the vulnerability specifically targets non-strict sloppy-mode functions where V8 substitutes the global object for undefined receivers, enforcing strict mode eliminates the condition under which this substitution occurs, thereby neutralizing the attack vector by preventing the leakage of the host global context into the untrusted environment.
From a classification perspective, this flaw aligns with CWE-20 Improper Input Validation and CWE-94 Code Injection, as it involves improper handling of input parameters leading to unauthorized code execution. In terms of adversary tactics, this vulnerability facilitates lateral movement within an application’s architecture by allowing initial access in the sandboxed context to pivot into the host environment, corresponding to ATT&CK techniques related to privilege escalation and defense evasion through process injection or command execution via system utilities like child_process. Security teams should audit their usage of vm2 for any exposed non-strict functions and prioritize patching to restore the integrity of the isolation boundary provided by the virtual machine implementation.