Critical Sandbox‑Escape Vulnerabilities Discovered in the vm2 Node.js Library

Multiple critical sandbox‑escape vulnerabilities have been disclosed in vm2, one of the most widely used Node.js sandboxing libraries, allowing attackers to break out of the isolated execution environment and execute arbitrary commands on the host system.

Eleven advisories were published by maintainer patriksimek within days, covering affected versions up to 3.11.1. Patches are available in vm2 3.11.0 and 3.11.1 for most issues, but two of the latest flaws remain unpatched as of the disclosure.

vm2 is a popular npm package that runs untrusted JavaScript code in a sandboxed environment. It is frequently deployed across multi‑tenant platforms, plugin systems, server‑side scripting engines, and CI/CD tools.

The library’s security promise is that code executed via VM.run() or NodeVM.run() cannot access the host system. This promise is entirely broken by the newly disclosed vulnerabilities.

All eleven issues carry a Critical CVSS v3.1 score, and several have publicly available proof‑of‑concept exploits demonstrating full remote code execution (RCE).

vm2 Node.js Library Flaws

The majority of the vulnerabilities stem from flaws in vm2’s internal “bridge” mechanism, which manages object references passing between the sandbox and the host JavaScript contexts.

Attackers repeatedly exploit the same design weakness: by manipulating internal JavaScript primitives such as __lookupGetter__, Buffer.apply, util.inspect, the Promise species, SuppressedError, and WebAssembly’s try_table instruction, they can obtain references to host‑realm objects—particularly Function.prototype—and then construct new functions that execute in the host context rather than the sandbox.

Once a host process object is obtained, commands such as child_process.execSync() can be invoked freely.

Notable Individual Vulnerabilities

CVE-2026-26956 targets Node.js v25 environments that use WebAssembly’s JSTag exception handling. By importing a JavaScript function that throws a Symbol‑to‑string TypeError and catching it at V8’s C++ level via a try_table instruction, attacker‑controlled code receives an unsanitized host‑realm error object, bypassing all of vm2’s JavaScript‑layer protections.

CVE-2026-43999 exposes a logic flaw in NodeVM’s builtin allowlist. When developers configure builtin: ['*', '-child_process']—a documented pattern—the module builtin is silently included. Because Module._load() runs in the host context, it can load any excluded module, including child_process, rendering the entire allowlist ineffective.

CVE-2026-44007 affects any application that uses nesting: true. This option injects vm2 into the sandbox regardless of require: false. A sandboxed script can call require('vm2'), construct a new inner NodeVM with unrestricted built‑in access, and achieve full RCE.

Two advisories—CVE-2026-44008 and CVE-2026-44009—remain unpatched at the time of disclosure, affecting all versions up to and including 3.11.1.

Organizations using vm2 should, where possible, immediately upgrade to version 3.11.1 and monitor the official GitHub repository for patches addressing CVE‑2026‑44008 and CVE‑2026‑44009.

Given the sustained pattern of escapes across every vm2 release, security teams should evaluate migrating to more hardened alternatives such as isolated‑vm or leveraging Deno’s permission model for executing untrusted code.

Any application exposing vm2 sandboxes to external user input should be considered critically exposed until the vulnerabilities are fully remediated.