CVE-2026-92953 in vm2
Summary
by MITRE • 09/17/2026
vm2 versions from 3.11.0 before 3.11.8 fail to protect host TypedArray and ArrayBuffer prototypes from sandbox mutation. Attackers can use prototype-walking primitives to reach and modify host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, causing host-created typed arrays to observe attacker-controlled properties after VM.run() returns.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in vm2 versions prior to 3.11.8 represents a critical failure in the isolation boundaries of the JavaScript sandboxing mechanism. Specifically, this flaw allows for prototype pollution attacks that target host-level TypedArray and ArrayBuffer prototypes. In standard Node.js environments, these objects are fundamental building blocks for handling binary data streams efficiently. The vulnerability arises because the sandboxed execution context does not sufficiently isolate its internal object structures from the global scope of the host environment. This lack of strict separation enables an attacker operating within the confined VM to access and manipulate the prototypes associated with high-level JavaScript types that exist outside the sandbox, thereby breaking the intended security model where untrusted code should remain completely isolated from trusted host resources.
From a technical perspective, the core issue lies in how vm2 handles prototype chains during object creation and property lookup. When an attacker executes malicious scripts within the VM, they can utilize specific JavaScript primitives to traverse up the prototype chain of objects created inside the sandbox. By exploiting these traversal mechanisms, it becomes possible to reach the host's Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype. Once access is gained to these prototypes, the attacker can inject malicious properties or overwrite existing methods. This modification persists even after the VM.run() function returns control to the main application thread. Consequently, any subsequent creation of typed arrays by the host environment will inherit these compromised prototype definitions, leading to unpredictable behavior, data corruption, or potential code execution depending on how those modified prototypes are utilized later in the application lifecycle.
The operational impact of this vulnerability is severe due to its persistence and broad scope. Because the modification affects global prototypes rather than just local variables within a single script invocation, the damage extends far beyond the immediate sandboxed context. Any part of the host application that relies on standard typed array operations may inadvertently execute attacker-controlled logic or behave erratically. This can lead to information disclosure if sensitive data is processed through modified methods, denial of service if critical functions are broken, or remote code execution if the prototype pollution facilitates further exploitation vectors such as type confusion attacks. The ability to mutate host prototypes effectively neutralizes the primary benefit of using a sandbox like vm2, which is to prevent untrusted code from affecting the stability and security of the surrounding system.
This vulnerability aligns with CWE-913, specifically Improper Control of Dynamically-Identified Variables, as it involves manipulating variables or objects that are identified at runtime through prototype chains rather than direct assignment. Furthermore, in terms of the MITRE ATT&CK framework, this behavior is characteristic of Defense Evasion techniques where attackers modify system components to avoid detection and maintain persistence within the application environment. The exploitation relies on indirect object reference manipulation, allowing the attacker to bypass standard access controls by leveraging the inherent flexibility of JavaScript's prototype-based inheritance model against a sandbox that fails to enforce strict boundaries between host and guest contexts.
To mitigate this risk, organizations must immediately upgrade vm2 to version 3.11.8 or later, where these prototype isolation issues have been addressed through stricter separation mechanisms. Until an update can be applied, developers should consider alternative sandboxing solutions such as Node.js Worker Threads, which provide native OS-level process isolation and do not suffer from the same JavaScript engine-specific prototype pollution vulnerabilities. Additionally, implementing strict Content Security Policies for any web-based interfaces interacting with these services can help limit the attack surface by restricting script execution sources. Regular auditing of dependencies is essential to ensure that known sandboxing flaws are patched promptly, as reliance on outdated versions leaves applications vulnerable to sophisticated prototype manipulation attacks that compromise both data integrity and system stability.