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.” 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.
First seen on csoonline.com
Jump to article: www.csoonline.com/article/4168568/13-new-critical-holes-in-javascript-sandbox-allow-execution-of-arbitrary-code.html
