Twelve Critical Sandbox Escape Vulnerabilities Disclosed in vm2 Node.js Library, Enabling Arbitrary Code Execution
A Dozen Critical Sandbox Escape Flaws Found in Popular 'vm2' Node.js Library
Related Entities
Products & Tech
Other
CVE Identifiers
MITRE ATT&CK Techniques
Full Report
Executive Summary
Researchers have disclosed a batch of twelve critical security vulnerabilities in vm2, a widely-used Node.js library designed to provide a secure sandbox for executing untrusted JavaScript code. These vulnerabilities can be exploited by malicious code running inside the sandbox to break out and achieve arbitrary code execution on the host operating system, completely defeating the library's purpose. Several of the flaws have been assigned a CVSS score of 9.8 (Critical). The maintainer of vm2, Patrik Simek, has released version 3.11.2 to address these issues and strongly advises all users to update without delay. This incident underscores the profound challenges of creating secure sandboxing environments in dynamic languages like JavaScript.
Vulnerability Details
The core issue across all twelve vulnerabilities is a failure in the sandboxing mechanism, allowing code within the vm2 environment to access and manipulate objects or functions in the parent Node.js process (the host). This is commonly referred to as a "sandbox escape." An attacker who can control the JavaScript code being run inside the sandbox can craft a payload to exploit one of these flaws.
Among the disclosed vulnerabilities, four have been highlighted with a critical CVSS score of 9.8:
- CVE-2026-24118: A sandbox escape that can be triggered via the
__lookupGetter__property, allowing access to the host context. - CVE-2026-24120: A bypass for a previously patched vulnerability (CVE-2023-37466). This new method exploits the
speciesproperty of promise objects to escape the sandbox. - CVE-2026-24781: A sandbox escape that leverages the
inspectfunction to gain access to host objects. - CVE-2026-26332: A sandbox escape that can be achieved by manipulating
SuppressedErrorobjects.
These vulnerabilities represent different logical flaws in the way vm2 isolates the guest code from the host environment.
Affected Systems
- Product: vm2 Node.js library
- Affected Versions: Versions up to and including 3.10.4 are affected by one or more of these vulnerabilities.
- Patched Version: 3.11.2
Any application that uses an affected version of the vm2 library to run untrusted or user-supplied JavaScript code is at risk.
Exploitation Status
While there are no public reports of active exploitation in the wild for these specific CVEs, the public disclosure of these vulnerabilities, coupled with their critical nature, means that proof-of-concept (PoC) exploits are likely to be developed quickly. Any system running a vulnerable version should be considered at high risk of exploitation.
Impact Assessment
The impact of a successful sandbox escape is severe. It completely nullifies the security boundary that vm2 is intended to provide. An attacker can execute arbitrary commands on the server hosting the Node.js application. This could lead to a full system compromise, allowing the attacker to:
- Steal sensitive data, including application source code, user data, and server credentials.
- Install persistent backdoors or ransomware.
- Use the compromised server to pivot and attack other systems within the internal network.
- Use the server's resources for malicious activities like cryptomining or participating in DDoS attacks.
For any service that relies on vm2 for security (e.g., online code editors, plugin systems, serverless function platforms), this vulnerability is a business-critical issue.
Cyber Observables — Hunting Hints
Detecting exploitation of these vulnerabilities can be challenging as it occurs within the application process. However, post-exploitation activity may be detectable.
The following patterns may help identify systems that have been compromised:
command_line_patternnode process spawning sh, bash, powershell.exenetwork_traffic_patternfile_namepackage-lock.json or yarn.lockvm2 older than 3.11.2 to identify vulnerable applications.Detection Methods
- Software Composition Analysis (SCA): The most effective detection method is to use an SCA tool (e.g., Snyk, Dependabot,
npm audit) to scan your projects' dependencies. These tools will flag the use of vulnerable versions of vm2 and point to the disclosed CVEs. This aligns withD3-SCA - Software Component Analysis. - Runtime Monitoring: Use an EDR or application security monitoring tool to detect anomalous behavior from your Node.js processes, such as unexpected file system access, process creation, or network connections.
Remediation Steps
- Update Immediately: The primary and most urgent remediation step is to update the vm2 library to the patched version, 3.11.2, or later. This can be done by running
npm install vm2@latestoryarn upgrade vm2@latestin your project directory. - Verify Update: After updating, check your
package-lock.jsonoryarn.lockfile to ensure that the resolved version of vm2 is indeed 3.11.2 or higher. - Consider Alternatives: Given the history of critical sandbox escape vulnerabilities in vm2, organizations should re-evaluate their reliance on it. The maintainer himself has noted the difficulty of securing it. Alternative sandboxing strategies, such as running untrusted code in separate, containerized environments (e.g., Docker) with strict resource limits and no network access, may provide a more robust security boundary. This is a form of
D3-HBPI - Hardware-based Process Isolationat a logical level.
Timeline of Events
MITRE ATT&CK Mitigations
Update Software
The most critical mitigation is to update the vm2 library to the patched version 3.11.2 or later.
Mapped D3FEND Techniques:
Given the recurring issues with vm2, consider running untrusted code in a stronger isolation primitive, such as a dedicated container (e.g., Docker) or micro-VM, to provide a hardware-enforced boundary.
Behavior Prevention on Endpoint
Use runtime security monitoring to detect post-exploitation behavior, such as a Node.js process spawning a shell or making unexpected network connections.
D3FEND Defensive Countermeasures
The immediate and most crucial action for any organization using the vm2 library is to update to the patched version, 3.11.2. This directly remediates the known sandbox escape vulnerabilities. This process should be automated as part of a robust patch management program. Developers should update their project's package.json file and run npm install or yarn upgrade to pull in the secure version. It is vital to then verify in the package-lock.json or yarn.lock file that the transitive dependencies have also resolved to the patched version. Given the critical 9.8 CVSS score, this update should be treated as an emergency change and deployed to all environments (development, staging, and production) as quickly as possible to close the window of opportunity for attackers.
To proactively manage risks from libraries like vm2, organizations must implement continuous Software Component Analysis (SCA). This involves integrating tools like npm audit, Snyk, or Dependabot into the CI/CD pipeline. These tools automatically scan all dependencies, including transitive ones, for known vulnerabilities like the dozen flaws in vm2. By running these scans on every code commit and on a regular schedule, teams can get immediate notifications when a vulnerability is discovered in a component they use. This allows for rapid identification of all affected applications across the enterprise, enabling a targeted and efficient patching response. SCA is a foundational practice for modern application security and is essential for defending against supply chain risks.
As a defense-in-depth strategy, organizations should consider moving away from process-level sandboxes like vm2 for running highly untrusted code. A more secure architectural pattern involves using stronger isolation boundaries. This could involve techniques like Process Segment Execution Prevention by running the untrusted JavaScript code in a completely separate process or, even better, a dedicated, minimal container (e.g., using Docker or gVisor) or a micro-VM (e.g., Firecracker). This container would have its own kernel context, a restricted file system, no network access by default, and strict CPU/memory limits. While this approach has higher overhead than vm2, it provides a much stronger security guarantee, as an escape would be contained within the ephemeral container and would not grant access to the host OS. This aligns with the principle of zero trust and is a more resilient long-term solution for handling untrusted code.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.