CVE-2026-92956 in vm2
Summary
by MITRE • 09/17/2026
vm2 versions 3.10.1 through 3.11.6 contain a sandbox escape reachable from a default `new VM()` sandbox when running on Node.js 26. WebAssembly.compileStreaming and WebAssembly.instantiateStreaming can produce a raw host-realm Promise that rejects with a host-realm error object; by controlling Symbol.species via Promise.prototype.finally, sandbox code receives that raw host error, walks from the host error constructor to the host Function constructor, and recovers the real host `process` object, gaining host Node.js capabilities (e.g. access to host modules such as fs) in the context of the process running the sandbox. No NodeVM, require permission, host object injection, or otherwise unsafe configuration is required. This is a bypass of the fix for GHSA-6j2x-vhqr-qr7q, which removed the JSPI entry points WebAssembly.promising and WebAssembly.Suspending. The issue is fixed in 3.11.7.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in vm2 versions ranging from 3.10.1 through 3.11.6 represents a critical sandbox escape mechanism that allows untrusted code to break out of the isolated execution environment and gain full access to the host Node.js process capabilities. This flaw is particularly severe because it operates effectively against the default configuration, meaning that simply instantiating a new VM without any special permissions or unsafe configurations such as host object injection enables this attack vector. The vulnerability serves as a bypass for previous security fixes, specifically GHSA-6j2x-vhqr-qr7q, which had attempted to mitigate similar risks by removing JavaScript Promise integration entry points like WebAssembly.promising and WebAssembly.Suspending. Despite these prior mitigations, the underlying issue persists through alternative pathways involving standard web APIs available in modern Node.js environments running on version 26 or higher.
The technical root cause of this vulnerability lies in how vm2 handles error objects originating from the host realm when they are processed within the sandboxed context via WebAssembly streaming functions. When a developer uses WebAssembly.compileStreaming or WebAssembly.instantiateStreaming, these APIs can produce raw promises that reject with errors belonging to the host realm rather than the sandbox's isolated realm. In normal circumstances, vm2 attempts to sanitize these objects by copying their properties into new instances within the sandbox context. However, this sanitization process fails when it encounters specific prototype chains involving Symbol.species on Promise.prototype.finally. By manipulating this property, an attacker can force the sandboxed code to receive a raw host-realm error object that has not been properly isolated from its constructor chain.
Once the sandboxed code obtains access to this raw host-realm error object, it can traverse the prototype chain starting from the error's constructor up to the global Function constructor in the host realm. This traversal is possible because vm2's proxying mechanism inadvertently exposes parts of the host environment's internal structure during property lookup operations on these specific objects. By reaching the host Function constructor, the attacker gains the ability to construct new functions that execute within the host context rather than the sandboxed one. From there, it becomes straightforward to recover the real host process object, which provides unrestricted access to Node.js core modules such as fs for file system manipulation, child_process for executing shell commands, and other sensitive APIs that were intended to be inaccessible from inside the VM.
The operational impact of this vulnerability is severe, effectively rendering the sandboxing mechanism useless against determined attackers who can control the input passed to vm2. Since no special configuration or elevated permissions are required within the VM options, any application using vulnerable versions of vm2 with default settings is at risk if it processes untrusted JavaScript code that interacts with WebAssembly streaming APIs. This could lead to remote code execution, data exfiltration, denial of service through resource exhaustion, or further lateral movement within a compromised system depending on the privileges of the Node.js process running the sandbox. The ability to access host modules means an attacker can read sensitive files, modify application state, or execute arbitrary commands with the same level of authority as the underlying server process.
To mitigate this risk, organizations must immediately upgrade vm2 to version 3.11.7 or later where these specific prototype chain traversal vectors have been patched and proper isolation boundaries are enforced for error objects originating from host-realm promises. In environments where upgrading is not immediately feasible, defensive coding practices should be implemented to strictly validate and sanitize all inputs before they enter the sandboxed context. Additionally, developers should consider avoiding WebAssembly streaming APIs within untrusted code blocks or implementing custom proxies that explicitly block access to Symbol.species on Promise prototypes during property lookups. Monitoring for unusual activity related to prototype chain traversal in JavaScript engines can also serve as an early detection mechanism for exploitation attempts targeting this class of sandbox escape vulnerabilities.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-755 Improper Handling of Exceptional Conditions, as it involves the failure to properly isolate exception objects from their host context leading to unauthorized access. In terms of offensive security frameworks, this technique maps closely to ATT&CK T1059 Command and Scripting Interpreter subcategories involving JavaScript execution and potentially T1620 Reflection-Based Evasion if attackers use similar techniques to hide malicious activity within legitimate web API calls. The persistence of such flaws despite previous fixes highlights the complexity of maintaining robust isolation boundaries in dynamic languages like JavaScript, where prototype chains and object prototypes provide powerful introspection capabilities that can be weaponized by adversaries to bypass security controls designed around static assumptions about object structure.