CVE-2026-92962 in vm2
Summary
by MITRE • 09/17/2026
vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of the vm2 library up to and including 3.11.3 represents a subtle but significant flaw in how the sandbox environment manages internal state during error handling operations. The core issue resides within the defaultSandboxPrepareStackTrace function located in lib/setup-sandbox.js, which is responsible for constructing output arrays used when generating stack traces for errors occurring inside or crossing the boundary of the virtual machine context. In these affected versions, the implementation utilizes prototype-walking index assignment to populate this array, specifically using the pattern lines[lines.length] = value. This approach relies on standard JavaScript property setting behavior, which interacts with the object's prototype chain if an own property does not already exist at that specific numeric index. Because the bridge-internal array is allocated within the sandbox realm itself rather than in a protected external context, it remains subject to manipulation by code executing inside the untrusted environment.
This architectural choice creates a direct avenue for information leakage through what can be classified as an information side channel vulnerability. An attacker controlling JavaScript execution within the vm2 sandbox can exploit this flaw by installing a custom accessor property on Array.prototype for the specific index that is being written to during stack trace generation. When the bridge code attempts to write data into the array using the vulnerable assignment method, it inadvertently triggers the prototype's accessor function defined by the malicious script. This allows the sandboxed code to observe and intercept every line of the stack trace as it is constructed, effectively breaking the isolation boundary intended by the vm2 library. The same vulnerability pattern exists in the error-handling catch branch, ensuring that this interception capability persists across different execution paths where errors are processed.
From a security classification perspective, this issue aligns with CWE-749: Exposure of Sensitive Information to an Unauthorized Actor and reflects weaknesses often associated with improper handling of prototype chains or global object pollution in JavaScript environments. While the practical impact is limited because the values being written are formatted strings rather than raw objects or references that could lead to arbitrary code execution, it still constitutes a violation of vm2's bridge-container defense invariant. The library relies on strict isolation between the host environment and the sandboxed context; allowing internal state manipulation via prototype pollution undermines this trust model. Consequently, while not a critical sandbox escape vulnerability in terms of immediate remote code execution potential, it represents a Low severity risk that compromises the integrity of debugging information and potentially aids further exploitation by revealing internal structures or timing data to an attacker within the sandbox.
The remediation for this issue was implemented in vm2 version 3.11.4 through a fundamental change in how array entries are assigned. Instead of relying on standard index assignment which traverses prototypes, the updated code utilizes Reflect.defineProperty to install each entry as an own data property directly on the target object. This technique bypasses prototype chains entirely, ensuring that even if Array.prototype has been polluted with custom accessors by sandboxed code, those interceptors are never triggered during internal bridge operations. Developers utilizing vm2 must upgrade to version 3.11.4 or later to mitigate this risk. Additionally, organizations should enforce strict dependency management policies and regularly audit third-party libraries for similar patterns where internal state is manipulated via prototype-interactable methods in sandboxed contexts. Monitoring for unexpected property accessors on global objects like Array.prototype can also serve as a detection mechanism for active exploitation attempts of such side-channel vulnerabilities.