Critical vm2 flaws let attackers escape Node.js sandboxes and run host commands

Multiple critical vulnerabilities in the vm2 Node.js sandbox library can let attackers break out of the sandbox and execute commands on the host system. The flaws affect applications that use vm2 to run untrusted JavaScript, including code runners, plugin systems, workflow tools, testing platforms, and internal automation services.

The newest safe upgrade target is vm2 version 3.11.2. The release includes security fixes for the latest sandbox escape issues, including flaws tied to null-prototype exception handling and Array species behavior.

The risk is serious because vm2 runs inside the same Node.js process as the host application. If sandboxed code escapes, it may reach host objects, load restricted modules, access the process object, and run operating system commands.

Why these vm2 vulnerabilities matter

vm2 is designed to run untrusted JavaScript with restrictions. Developers use it when they need to let users, plugins, scripts, or automated systems execute code without exposing the main application.

The new advisories show that this security boundary can fail in several ways. Some issues abuse JavaScript prototype behavior, Promise species handling, exception logic, WebAssembly behavior, or module loading rules.

In practical terms, an attacker who can submit code into a vulnerable vm2 sandbox may escape into the host environment. From there, they may run commands with the privileges of the Node.js process.

At a glance

Detail	What it means
Affected package	vm2 for Node.js
Main impact	Sandbox escape and arbitrary command execution on the host
High-risk use cases	Code execution platforms, plugin systems, CI tools, automation platforms, and multi-tenant services
Latest fixed version	3.11.2
Recommended action	Update immediately and add stronger isolation around untrusted code

Which vm2 flaws were disclosed

The disclosed issues include several critical sandbox escapes with CVSS scores reaching 10.0. Affected versions vary by vulnerability, but older releases before 3.11.2 should be treated as risky in environments that execute untrusted code.

One issue, CVE-2026-24118, abuses __lookupGetter__ behavior to reach host-side objects and execute commands. Another, CVE-2026-24120, bypasses a previous Promise species fix and can again lead to command execution.

Other flaws involve inspect handling, SuppressedError behavior, prototype traversal, restricted module loading, prototype pollution, null-prototype exceptions, and Array species handling. CVE-2026-26956 is also notable because it involves WebAssembly behavior and was confirmed in a Node.js 25 environment.

Key CVEs and patch status

CVE	Issue type	Fixed in
CVE-2026-24118	Sandbox breakout through __lookupGetter__	3.11.0
CVE-2026-24120	Promise species sandbox escape	3.10.5
CVE-2026-24781	Sandbox escape through inspect behavior	3.11.0
CVE-2026-26332	Sandbox escape through SuppressedError behavior	3.11.0
CVE-2026-26956	WebAssembly-related sandbox escape	3.10.5
CVE-2026-43997	Code injection leading to host object access	3.11.0
CVE-2026-43999	NodeVM built-in allowlist bypass	3.11.0
CVE-2026-44005	Sandbox escape and prototype pollution	3.11.0
CVE-2026-44006	BaseHandler.getPrototypeOf code injection	3.11.0
CVE-2026-44007	Improper access control sandbox escape	3.11.1
CVE-2026-44008	Array species sandbox escape	3.11.2
CVE-2026-44009	Null-prototype exception sandbox escape	3.11.2

How attackers can abuse these flaws

The attack path depends on where vm2 sits in an application. If a service lets users submit JavaScript for execution, an attacker may send crafted code that triggers one of the sandbox escape paths.

After the escape, the attacker may reach the host Function constructor or process object. That can allow access to Node.js internals and restricted modules such as child_process.

Once command execution works, the impact depends on the permissions of the Node.js process. A poorly isolated service could expose files, environment variables, access tokens, cloud credentials, internal network access, or build secrets.

Who should act first

• Services that run user-submitted JavaScript
• Online code editors and coding challenge platforms
• Plugin systems that execute third-party scripts
• CI/CD tools that evaluate scripts dynamically
• Low-code and workflow automation platforms
• Multi-tenant SaaS products that rely on JavaScript sandboxing
• Internal tools that run scripts from tickets, dashboards, or user input

Updating vm2 is not the full fix

Developers should update to vm2 3.11.2 immediately. This reduces exposure to the newly disclosed flaws and brings the package to the latest security-fixed release.

Still, the vm2 project warns that in-process JavaScript sandboxing has limits. Its own documentation now explains that JavaScript is highly dynamic and that new bypasses may continue to appear.

For high-risk workloads, teams should not rely on vm2 as the only security layer. Running untrusted code in a separate process, container, microVM, or managed isolation environment gives defenders a stronger boundary than an in-process JavaScript sandbox.

Practical steps for developers

• Upgrade vm2 to version 3.11.2 across all projects.
• Search package-lock.json, pnpm-lock.yaml, yarn.lock, and SBOM files for older vm2 versions.
• Check transitive dependencies that may still pull vulnerable vm2 releases.
• Disable execution of untrusted code until the update is deployed.
• Run sandbox workloads with least-privilege user accounts.
• Move high-risk execution to containers, microVMs, or separate processes.
• Restrict filesystem, network, and environment variable access for sandbox workers.
• Rotate exposed secrets if suspicious sandbox execution occurred.

Why stronger isolation matters

The core lesson is simple: a JavaScript-only sandbox can reduce risk, but it should not define the entire security boundary for hostile code. Attackers only need one bypass to move from sandboxed code to the host process.

Containers and microVMs are not perfect, but they create a separate operating system boundary. That gives defenders more places to enforce limits, monitor behavior, and contain damage.

Teams that run untrusted JavaScript should treat vm2 as one layer in a larger design. The safer architecture limits what the sandboxed process can read, where it can connect, and which credentials it can access.

FAQ