CVE-2026-92950 in vm2
Summary
by MITRE • 09/17/2026
vm2 before 3.11.7 contains a sandbox escape vulnerability in the CLI tool that allows attackers to execute arbitrary code in the host Node.js process. Attackers can supply a malicious script file to the vm2 CLI that uses require(__filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and child_process.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of vm2 prior to 3.11.7 represents a critical failure in the security model designed to isolate untrusted JavaScript code from the host environment. The core issue lies within the command-line interface tool provided by the library, which is intended for executing scripts within a sandboxed context. This isolation mechanism relies on restricting access to sensitive Node.js modules and preventing direct interaction with the global scope of the parent process. However, the implementation contains a flaw that allows an attacker to bypass these restrictions through a specific technique involving self-referential script execution. By supplying a maliciously crafted script file to the vm2 CLI tool, an adversary can exploit this weakness to escape the sandbox and gain full control over the host Node.js process.
The technical mechanism of this exploitation centers on the use of require(__filename). In standard Node.js environments, __filename resolves to the absolute path of the currently executing script module. When a malicious script invokes require with its own filename, it triggers the CommonJS module loading system to load and execute that same file again. Crucially, in the context of this vulnerability, this re-execution occurs outside the sandboxed realm established by vm2. Instead of running within the restricted environment where access to host modules is blocked, the code executes in the global scope of the parent Node.js process. This effectively neutralizes the isolation guarantees provided by the library, as the attacker gains unrestricted access to all built-in modules and APIs available to the main application.
The operational impact of this sandbox escape is severe, enabling arbitrary code execution on the host system with the same privileges as the user running the vm2 CLI tool. Once inside the host realm, an attacker can leverage standard Node.js capabilities such as fs for file system operations or child_process for spawning new processes. This allows for a wide range of malicious activities including reading sensitive configuration files, modifying data stored on disk, installing backdoors, or executing arbitrary shell commands. The severity is further amplified by the fact that CLI tools are often used in automated pipelines or development workflows where input sources might not be fully trusted, increasing the attack surface for potential exploitation against developers and CI/CD systems.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves injecting code into a host environment through improper validation of script inputs. Additionally, from an adversary perspective, this technique maps to ATT&CK T1059 Command and Scripting Interpreter subcategories such as JavaScript or Node.js, specifically illustrating how attackers can abuse legitimate tools for lateral movement or privilege escalation within the execution context. The exploitation path demonstrates a classic failure in boundary enforcement where internal state manipulation leads to security bypasses.
To mitigate this risk, organizations must immediately upgrade vm2 to version 3.11.7 or later, which addresses the sandbox escape vector by patching the CLI tool's handling of module loading and execution contexts. For environments that cannot update immediately, it is advisable to avoid using the vm2 CLI with untrusted input sources entirely. Instead, scripts should be validated rigorously before execution, and alternative isolation mechanisms such as containerization or separate user accounts with restricted permissions should be employed to limit the blast radius of any potential compromise. Regular auditing of dependencies for known vulnerabilities in sandboxing libraries is essential to maintain a robust security posture against code injection attacks.