Critical vm2 sandbox flaw lets untrusted code break out to the host

The maintainers of vm2, a widely used Node.js sandbox library, have disclosed a critical vulnerability that can let untrusted JavaScript escape its sandbox and execute code on the host machine. The flaw is tracked as CVE-2026-26956, affects vm2 version 3.10.4, and arrives with public proof-of-concept exploit code already available.

This matters because vm2 is one of the standard tools developers reach for when they need to run user-supplied JavaScript inside a supposedly restricted environment. It shows up in online coding platforms, automation products, AI tooling, and SaaS applications that let customers execute scripts. When a sandbox escape lands in software like this, the problem is not a neat theoretical bug. It is a direct question of whether untrusted tenant code can turn into host-level compromise.

According to the maintainer advisory and reporting from BleepingComputer, the bug is tied to the way vm2 handles exceptions crossing between the sandbox and the host. In the affected setup, WebAssembly exception handling can bypass vm2's JavaScript-level protections inside the V8 engine. That can let a host-side error object leak back into the sandbox, where attackers can abuse the constructor chain to regain access to Node.js internals such as the process object and ultimately execute arbitrary commands on the host.

The exposure is not universal across every Node.js deployment. The advisory says the issue has been confirmed on Node.js 25.6.1 in environments that have WebAssembly exception handling and JSTag support enabled. That technical scope matters, but it should not create false comfort. vm2 is downloaded more than a million times per week on npm, and libraries like this are often buried deep inside larger products, internal tools, or customer extensibility features that teams do not inventory carefully enough.

The more urgent detail is that exploit code is already public. Once a sandbox escape has both a CVE and a public proof of concept, the gap between disclosure and opportunistic exploitation tends to shrink quickly, especially in internet-facing services that execute user workflows, code snippets, or automation steps. If a company uses vm2 to isolate untrusted logic, it needs to assume attackers will test that boundary now, not later.

The patch path is straightforward. Users should move off vm2 3.10.4 immediately and upgrade to version 3.10.5 or later, with 3.11.2 currently available. But patching alone is not the whole response. Teams should also identify where vm2 is embedded, confirm whether affected Node.js 25 configurations are in use, and review any product surfaces where outside users can submit code that eventually reaches a vm2 sandbox.

This disclosure also fits a broader pattern. vm2 has been hit by multiple serious sandbox escape bugs over the last few years, which raises a hard but increasingly important engineering question: how much real isolation does a JavaScript sandbox provide once attackers start finding paths around language-level defenses? For teams building platforms on top of user-executed code, that question is becoming architectural rather than incidental. As first reported by BleepingComputer, the safest response here is not just to patch quickly, but to re-check how much trust is being placed in vm2 in the first place.