Thirteen critical vulnerabilities have been found in the vm2 JavaScript sandbox package that could allow an attacker’s code to escape the container and do nasty things to IT environments. As a result, developers using this library in their applications are urged to update the software to the latest version, which is currently 3.11.2.
The warnings come in advisories from vm2 maintainer Patrik Simek.
vm2 is an open source vm/sandbox that can run untrusted code with whitelisted Node.js’s built-in modules.
One of the more serious of the 13 vulnerabilities is CVE-2026-26956, a full sandbox escape with arbitrary code execution. Attacker code that is inside VM.run() can obtain host process object and runs host commands with zero co-operation from the host.
However, researchers at Socket told us in an email that the advisory about this escape says it has been confirmed only on Node.js 25.6.1, and requires a Node.js version with WebAssembly exception handling and JSTag support.
The highest-risk scenario, they said, would be an application using vm2 version 3.10.4 on Node 25, where attacker-controlled JavaScript is passed into VM.run().
“This is a narrow but high-impact vulnerability,” Socket research engineer Wenxin Jiang said in an email. “It does not appear to affect every vm2 deployment, because the advisory points to a specific vulnerable version and a specific Node 25/WebAssembly combination. But when those conditions line up, the security boundary fails completely: code that was supposed to be confined to the sandbox can reach the host process and execute commands. That is why teams using vm2 for user-supplied JavaScript should patch quickly and review what the sandboxed process can access.”
Although it is not a vm2 maintainer, Socket said it is issuing a patch for developers who can’t immediately upgrade to the latest, fixed version.
Another serious hole is CVE-2026-44007, an improper access control vulnerability in the vm2 Node.js library that allows sandbox escape and execution of arbitrary operating system commands on the underlying host. Its advisory says that the vulnerability is in how the nesting:true option interacts with the legacy module resolver. This was patched in vm2 version 3.11.1.
“For CSOs, both [vulnerabilities] deserve urgent attention,” said Jiang, “but the second [the NodeVM nesting issue] may be the one more organizations need to audit for immediately.”
Both flaws, said Socket researchers, can turn sandboxed JavaScript into command execution on the host system. The difference is in how many environments are likely to be exposed. The Node 25/WebAssembly issue appears narrower because it depends on a specific vm2 version and a specific newer Node.js runtime behavior. The NodeVM nesting issue may be broader because it affects more versions and is triggered by a configuration pattern that some developers may have used intentionally.
Jiang added that both advisories point to a broader lesson: JavaScript sandboxes are difficult to secure, and small differences in runtime behavior or configuration can have major security consequences. “The first issue appears tied to a narrow Node 25/WebAssembly path,” he said. “This second issue is a configuration-driven escape involving NodeVM and nesting:true.
In both cases, the highest-risk users are organizations that run untrusted JavaScript and assume vm2 is containing it. Those [application development] teams should patch immediately and add stronger isolation around sandboxed workloads.”
‘Fragile security model’
These sandbox escape vulnerabilities demonstrate why sandboxing untrusted code inside a trusted process is a fragile security model, Adam Reynolds, senior security researcher at Sonatype, said in an email. “Once untrusted code runs inside a process with access to credentials and secrets, the underlying filesystem, the network, or with deployment privileges, a sandbox bypass can easily lead to a full system compromise,” he said.
Simply having vm2 installed somewhere in the dependency tree is not enough to make some of these vulnerabilities exploitable, he added. For example, an attacker generally needs the ability to execute crafted JavaScript (and in the case of CVE-2026-26956, crafted WebAssembly) inside a vm2 sandbox controlled by the vulnerable application. If the application never instantiates vm2, only uses it for trusted internal scripts, or does not allow attacker-controlled code execution at all, then there may be no realistic exploit path despite the presence of the dependency.
If an organization is running any applications impacted by vm2, they should be upgraded immediately, he said. To mitigate risk until the upgrade is complete, users can avoid Node.js 25 runtimes, disable or block WebAssembly entirely inside untrusted sandboxes, and prevent user-controlled WASM compilation/execution.
“Since future runtime updates could lead to similar issues, vm2 should be viewed as a convenience isolation layer as opposed to a hard security boundary,” he added.
In addition, Robert Enderle of the Enderle Group said that IT leaders who are serious about security should stop relying on software-level sandboxing for untrusted code. Start looking at moving those processes into hardened Docker containers or V8 Isolates, he advised.