CVE-2026-26956: vm2 Sandbox Escape Enables Host RCE in Node.js 25

CVE-2026-26956 is a critical sandbox escape affecting the Node.js sandbox library vm2. In vm2 3.10.4, attacker-controlled JavaScript executed through VM.run() can break out of the sandbox and reach the host process object, leading to arbitrary code execution (RCE) in the host Node.js process.

This post explains what the vulnerability is, who is affected, how the escape works at a high level, what is known about exploitation, and what defenders should do next.

What Is CVE-2026-26956 in vm2?

CVE-2026-26956 (CVSS 9.8) is a full sandbox escape in vm2, an npm package designed to run untrusted JavaScript with restrictions such as a limited module allowlist. Under the affected conditions, code that is supposed to stay contained inside vm2 can instead access objects from the host realm.

Once the attacker obtains the host process object, the sandbox boundary effectively collapses. From there, a typical next step is loading Node’s child_process module and running operating system commands, resulting in host-level RCE in the context of the Node process running vm2.

Which vm2 and Node.js Versions Are Affected?

The affected vm2 version is 3.10.4, and the vulnerability is fixed in 3.10.5 (upgrade to 3.10.5+).

Environment constraints matter for exposure. The sandbox escape is Node.js 25 specific and was confirmed on Node.js v25.6.1 (x64 Linux). Exploitation requires a Node.js build that includes WebAssembly exception handling and WebAssembly.JSTag support, which is part of why this CVE is scoped to Node 25 in the advisory.

If you run vm2 but are not on Node.js 25, treat this as a reminder that JavaScript-level sandboxing is brittle, but the specific CVE preconditions may not be met in your environment.

How Does Exploitation Lead to a Sandbox Escape and Host RCE?

vm2’s core sandboxing approach relies heavily on JavaScript-level controls, including rewriting catch clauses to funnel exceptions through a handler and using proxy-based bridging for objects that cross the sandbox boundary.

CVE-2026-26956 bypasses those protections by abusing WebAssembly exception handling. In simplified terms:

• The attacker uses WebAssembly constructs (try_table with a JSTag catch handler) to catch a JavaScript exception at a lower level than vm2’s rewritten catch logic.
• That exception can be returned back into attacker-controlled code as a value, without passing through vm2’s normal sanitization and wrapping.
• The returned “host realm” error object can then be used to reach powerful constructors (the classic constructor.constructor path) and ultimately obtain the host process object.

The proof of concept described in the advisory uses a TypeError triggered during stack formatting via Symbol-to-string coercion (for example, manipulating an error name with Symbol() and then touching e.stack) as part of the chain that produces a useful host exception object.

How Severe Is CVE-2026-26956 and What Is the Real Impact?

The assigned severity is CVSS 9.8 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In practical terms, this means: if an attacker can influence code executed inside VM.run(), they may gain code execution on the host without credentials or user interaction.

This is highest risk for environments that use vm2 for:

• Multi-tenant scripting features
• Plugin execution systems
• “Run user code” features in CI, automation, or workflow platforms
• Any service that treats vm2 as a security boundary against hostile input

Because the compromise occurs inside the host Node process, the attack surface depends on the privileges of that process, including secrets in environment variables, filesystem access, network reachability, and any cloud credentials available at runtime.

Is There Active Exploitation or a Public PoC?

A working Proof-of-Concept (PoC) is available in the CVE-2026-26956 security advisory, and it demonstrates both sandbox escape and host command execution. This lowers the barrier for operationalizing the issue in real attacks, especially against applications that expose scripting features.

There is no authoritative confirmation of in-the-wild exploitation and no indication that the CVE has been added to CISA’s Known Exploited Vulnerabilities catalog. That can change quickly once PoC code circulates, so avoid using “no confirmed exploitation” as a reason to delay remediation.

How SOCRadar Helps Security Teams Respond

When critical vulnerabilities gain public PoCs or begin drawing attacker attention, security teams need to understand both exploitation activity and exposure across their environment. SOCRadar Cyber Threat Intelligence helps organizations monitor CVE developments, exploit maturity, PoC availability, attacker discussions, related IOCs, and emerging exploitation trends tied to high-risk vulnerabilities.

Alongside this, SOCRadar Attack Surface Management (ASM) helps identify exposed assets, internet-facing services, and risky configurations that could increase the likelihood of exploitation. Together, these capabilities help teams prioritize remediation efforts based on real-world risk.

SOCRadar Vulnerability Intelligence

What Should Defenders Do Now to Reduce Risk?

Upgrade immediately

• Upgrade vm2 to 3.10.5 or later. Many teams will choose to move to the latest available vm2 release rather than stopping at the minimum fixed version.
• Note: vm2 has a long history of critical sandbox escapes and its maintainers have officially deprecated the project. Beyond patching to 3.10.5, teams should prioritize migrating to an actively supported alternative such as isolated-vm.

Validate whether you are actually exposed

• Identify where your codebase calls VM.run() (or equivalent vm2 execution paths) with untrusted input.
• Confirm runtime versions, especially whether production workloads run on Node.js 25.x and whether the required WebAssembly features are present.

Add defense-in-depth for “run untrusted code” features

Even with a patch, sandbox escapes are a recurring risk for this category of tooling. If you must execute hostile code:

• Isolate execution at the container or VM boundary with least privilege.
• Remove sensitive environment variables and credentials from the execution context.
• Monitor for unexpected use of child process execution originating from the service that hosts untrusted code, since post-escape activity often pivots through child_process.

Operationalize detection and response

• Inventory services that depend on vm2 directly or transitively.
• Prioritize patching for internet-facing or multi-tenant systems first.
• Treat suspicious behavior as potential host compromise, not just a “sandbox bug,” because the end state is host RCE in the Node process.

By identifying where untrusted code enters vm2, confirming whether Node.js 25 is in play, and upgrading past vm2 3.10.4, teams can reduce risk from CVE-2026-26956.