Public vm2 PoCs released, raising ESXi host‑escape risk

Sandbox escapes in vm2 are back in the spotlight because working proof-of-concept code is now public for two fresh critical bugs, and that changes the risk from “patch when you can” to “assume someone will try this.” vm2 is a Node.js library people use when they want to run untrusted JavaScript inside a supposedly fenced-off environment. The whole point is that the code stays trapped. But these bugs let code hop the fence and execute on the underlying host process instead. GitHub advisories for CVE-2026-26332 and CVE-2026-26956 went live in the first week of May, and public writeups followed right behind. ### What is vm2 actually protecting? vm2 is not a hypervisor and not a container runtime. It is a JavaScript sandbox inside a Node.js process. Developers use it for things like plugin systems, online code runners, automation platforms, and any service that lets users submit code or expressions. If that sandbox breaks, the attacker does not just escape to “more JavaScript” — the attacker can often reach the host `process` object and then spawn commands with the same privileges as the Node service. That is why these bugs are so ugly. ### What changed this week? The big change is public exploit detail. CVE-2026-26332 was published on May 1 and updated May 5, with a PoC that uses `SuppressedError` to break out of vm2 3.10.4 on Node.js v24.13.0. CVE-2026-26956 was published a few days later, with a PoC showing a WebAssembly-based escape on vm2 3.10.4 running Node.js v25.6.1. In both cases, the sample code reaches the host process and then executes a system command. That means defenders are no longer reacting to a theoretical flaw — they are reacting to a recipe. ### Why are there two different bugs? Because vm2’s isolation lives at the JavaScript layer, and both bugs slip underneath pieces of that logic in different ways. The `SuppressedError` bug abuses newer JavaScript error-handling behavior. The WebAssembly bug is nastier in a different way — it uses exception handling in WASM to catch a host-side error below JavaScript’s normal wrapping logic, then hands that error object back to attacker-controlled code unsanitized. From there, the constructor chain becomes the ladder out. Basically, the sandbox thinks it is filtering dangerous objects, but the object comes back through a side door. ### So where does ESXi come in? This is the part to say carefully: the confirmed bugs are in vm2, not in ESXi itself. But if a management appliance, extension, plugin service, or automation layer tied to vCenter or adjacent VMware infrastructure uses vulnerable vm2 to run untrusted code, then a sandbox escape could become host-level code execution inside that management environment. And once an attacker lands in a privileged management plane, the blast radius can include ESXi hosts, credentials, backups, and orchestration. The risk is indirect but very real. There is no broad public proof here that “ESXi is vulnerable by default” from vm2 alone. The danger is the software stack around it. ### Which versions are affected? CVE-2026-26332 affects vm2 through 3.10.4 and is patched in 3.11.0. CVE-2026-26956 affects vm2 3.10.4 and is patched in 3.10.5, with the advisory noting a Node 25-specific WASM path. Both are rated critical. ### What should defenders do first? Find every place vm2 is embedded — directly or transitively. Then patch fast, or disable the feature that runs untrusted code until you can. After that, treat management systems as high-value targets: lock down admin interfaces, require MFA, rotate exposed credentials, and verify that backups can actually restore cleanly. If a service was using vm2 as its main safety boundary, assume that boundary failed. ### What’s the bottom line? This is not “just another Node bug.” It is a reminder that language-level sandboxes are brittle, and once public PoCs exist, the window between disclosure and abuse gets short. If vm2 sits anywhere near your virtualization control plane, that is the path to scrutinize right now.