Critical vulnerabilities have been discovered in the vm2 library, a popular tool for running untrusted JavaScript code in an isolated Node.js environment. These flaws make it possible to break out of the sandbox and execute arbitrary code on the host system. A previously identified vulnerability, CVE-2026-22709, received a 9.8 out of 10 CVSS score, which corresponds to a critical severity level. Reportedly, the new security issues continue a series of sandbox escapes, calling into question the reliability of JavaScript sandboxes as a class of solutions for isolating untrusted code.

Technical details

The vm2 library is an open source project that, according to its developers, provides secure execution of untrusted JavaScript code by intercepting and proxying JavaScript objects, preventing the isolated code from accessing the host environment. The library is widely used in projects that need to run user-provided or third-party code — from automation platforms to online code editors.

The confirmed vulnerability CVE-2026-22709 has a CVSS score of 9.8, which indicates the possibility of remote, unauthenticated exploitation with full compromise of the confidentiality, integrity, and availability of the host system. The vulnerability belongs to the sandbox escape class and allows an attacker who controls the code executed inside the sandbox to gain access to the underlying operating system’s resources.

The source material points to the discovery of numerous additional critical vulnerabilities in vm2; however, the specific list of CVE identifiers for these vulnerabilities is not provided in the available primary sources, which prevents independent verification of the exact number and nature of all the reported issues. The current status of active exploitation of these vulnerabilities is unknown; CVE-2026-22709 is not listed in the CISA KEV catalog.

A systemic issue with JavaScript sandboxes

The series of vm2 sandbox escapes illustrates the fundamental difficulty of reliably isolating untrusted code in a JavaScript environment. The vm2 security model is based on object proxying — an approach that is inherently prone to bypasses via non-obvious access paths to prototypes, the execution context, or internal mechanisms of the V8 engine.

According to the researchers, the project maintainer Patrick Schimke himself acknowledged that discovering new sandbox bypasses in the future is quite likely. This statement is significant: it means that the developer recognizes the architectural limitations of the chosen isolation approach. For projects that critically depend on the reliability of the sandbox, this is a signal to reconsider their architectural decisions.

Impact assessment

The highest risk applies to:

• Platforms running user code — services that allow customers to upload and execute JavaScript (automation platforms, serverless functions, plugins)
• CI/CD systems that use vm2 for isolated execution of build or test scripts
• Node.js server applications that process templates or expressions supplied by users

Successful exploitation of a sandbox escape vulnerability with a 9.8 CVSS score can lead to full server compromise: execution of arbitrary commands, data theft, installation of malware, or using the compromised host for further movement within the infrastructure.

Practical recommendations

1. Dependency audit: check whether vm2 is used in your projects — either as a direct dependency or a transitive one. The command npm ls vm2 will show whether the library is present in the dependency tree.
2. Update: install the latest available version of vm2 that includes fixes for CVE-2026-22709. Check the NVD entry for up-to-date information on affected and fixed versions.
3. Evaluate alternatives: for critical scenarios, consider more robust isolation mechanisms — containers with restricted privileges, separate processes combined with Worker Threads and OS-level restrictions, or solutions based on WebAssembly.
4. Principle of least privilege: the Node.js process using vm2 should run with minimal privileges in the operating system. This will limit damage in the event of a successful sandbox escape.
5. Monitoring: configure monitoring for anomalous activity of Node.js processes — spawning child processes, accessing the file system outside the working directory, or establishing network connections to unusual destinations.

The discovery of a series of critical sandbox escape vulnerabilities in vm2 is not just another incident that requires a dependency update. It is a reason for an architectural decision: if your project relies on vm2 as the sole barrier between untrusted code and the host system, you need either to add additional layers of isolation (containerization, OS-level restrictions) or switch to a fundamentally different mechanism for executing untrusted code. The priority is to immediately update vm2 and simultaneously evaluate architectural alternatives.