Executive Intelligence Brief
A critical vulnerability in vm2, a popular Node.js sandboxing library, allows attackers to escape the sandbox and execute arbitrary JavaScript in the host process. This is achieved by exploiting the node:test module, which can be exposed to sandboxed code when explicitly allowed by the embedder. The vulnerability affects vm2 versions >=3.9.6 and <=3.11.5 on Node.js 24 and newer. Immediate patching or mitigation is recommended to prevent potential sandbox escapes and host compromise.
Threat Overview
The vm2 library provides a sandboxing environment for executing untrusted JavaScript code in Node.js. It allows developers to restrict the access of sandboxed code to certain modules and resources. However, a vulnerability in vm2's handling of the node:test module allows attackers to bypass the sandbox and execute arbitrary JavaScript in the host process.
The node:test module is a built-in module in Node.js 24 and newer that provides a testing framework. When the embedder explicitly allows the node:test module in the vm2 configuration, sandboxed code can access it through require('node:node:test'). The node:test.run() function, which starts a separate Node process for test execution, can be called with attacker-controlled execArgv values. By supplying --eval=
Technical Deep Dive
Vulnerability Classification
The vulnerability can be classified as CWE-918: Server-Side Request Forgery (SSRF). The vulnerability occurs due to the improper handling of the node:test module in vm2, allowing an attacker to make a request to the host process's file system and execute arbitrary JavaScript.
Root Cause Analysis
The root cause of the vulnerability is the combination of builtin admission, generic host passthrough, and prefix normalization in vm2. Specifically:
- On Node.js 24+, module.builtinModules includes the scheme-only key node:test.
- lib/builtin.js builds BUILTIN_MODULES from that array, but the family-based DANGEROUS_BUILTINS protection does not include test.
- When the embedder explicitly allows node:test, addDefaultBuiltin() stores it through the generic loader.
- In lib/setup-node-sandbox.js, requireImpl() strips one node: prefix before builtin lookup.
Consequently, sandbox code requesting node:node:test is normalized to the stored key node:test and receives a readonly proxy to the host module. The readonly proxy does not make node:test.run() safe, as calls are forwarded to the host implementation, which accepts attacker-controlled execArgv for a newly spawned Node process.
Attack Vector & Chain
The attack vector involves an attacker intentionally permitted to execute untrusted JavaScript in the affected NodeVM configuration. The attacker can escape the sandbox and execute arbitrary JavaScript under the embedder's operating-system identity.
The attack chain involves:
- Initial access: The attacker executes untrusted JavaScript in the affected NodeVM configuration.
- Weaponization: The attacker requires the node:node:test module and calls node:test.run() with attacker-controlled execArgv.
- Delivery & Exploitation: The attacker supplies --eval=
in execArgv, which executes arbitrary JavaScript in an unrestricted host Node process. - Post-Exploitation: The attacker can execute arbitrary JavaScript in the host process, potentially leading to complete confidentiality, integrity, and availability impact.
Exploitation Scenario Walkthrough
Scenario: vm2 Sandbox Escape via node:test.run()
Reconnaissance: An attacker identifies a vulnerable version of vm2 and a Node.js environment that allows the node:test module.
Weaponization: The attacker prepares a malicious JavaScript payload that requires the node:node:test module and calls node:test.run() with attacker-controlled execArgv.
Delivery & Exploitation: The attacker executes the malicious JavaScript in the affected NodeVM configuration, which leads to the execution of arbitrary JavaScript in the host process.
Post-Exploitation: The attacker can execute arbitrary JavaScript in the host process, potentially leading to complete confidentiality, integrity, and availability impact.
Impact Realization: The attacker achieves arbitrary code execution in the host process, potentially leading to a complete compromise of the hosting service.
Exploitation in the Wild
The vulnerability is not actively exploited in the wild, but it is likely that attackers will exploit it given its severity and potential impact.
Impact Analysis
Direct Impact
The direct impact of the vulnerability is the ability for an attacker to escape the vm2 sandbox and execute arbitrary JavaScript in the host process. This can lead to complete confidentiality, integrity, and availability impact for the hosting service.
Downstream & Cascading Effects
The downstream and cascading effects of the vulnerability include:
- Supply chain risk: If the vulnerable vm2 library is used in a supply chain, an attacker could exploit the vulnerability to compromise the supply chain.
- Regulatory implications: The vulnerability could lead to regulatory issues if the compromised hosting service handles sensitive data.
- Customer data exposure: The vulnerability could lead to customer data exposure if the compromised hosting service stores sensitive customer data.
Affected Products & Versions
The affected products and versions are:
- Package: vm2
- Affected versions: >=3.9.6, <=3.11.5
- Latest reproduced version: 3.11.5
- Reproduced runtime: Node.js v24.18.0
Detection & Threat Hunting
Indicators of Compromise
The indicators of compromise include:
- Unusual activity in the Node.js process
- Unexpected network communications
- Anomalous file system access
Detection Rules & Signatures
The detection rules and signatures include:
- Monitoring Node.js process activity for unusual behavior
- Detecting unexpected network communications
- Identifying anomalous file system access
Threat Hunting Queries
The threat hunting queries include:
- Searching for suspicious Node.js process activity
- Identifying potential exploit attempts
- Detecting anomalous file system access
Remediation & Hardening
Immediate Actions (0-24 hours)
The immediate actions include:
- Patching to a non-vulnerable version of vm2 (e.g., vm2@3.11.6 or later)
- Restricting access to the node:test module
Short-Term Hardening (1-7 days)
The short-term hardening measures include:
- Implementing additional security controls, such as network segmentation and access restrictions
- Enhancing monitoring and detection capabilities
Strategic Recommendations
The strategic recommendations include:
- Regularly updating and patching dependencies
- Implementing secure coding practices
- Conducting regular security audits and risk assessments
Analyst Assessment
The analyst assessment is that the vulnerability is severe and likely to be exploited by attackers. It is essential to patch or mitigate the vulnerability as soon as possible to prevent potential sandbox escapes and host compromise.
Sources
- GitHub Security Advisories: vm2: NodeVM builtin allowlist bypass via node:test.run() execArgv allows sandbox escape