Socket is releasing free Certified Patches for a critical sandbox escape vulnerability in vm2, a JavaScript sandboxing library used to run untrusted code inside Node.js applications.

The vulnerability, tracked as GHSA-ffh4-j6h5-pg66 and CVE-2026-26956, allows attacker-controlled JavaScript executed through VM.run() to escape the sandbox, access the host Node.js process object, and execute arbitrary operating system commands.

The current GitHub advisory identifies vm2 3.10.4 as affected and describes the issue as “Node 25 only.” While preparing certified patches for the vulnerability, we found that the affected range is broader. Socket’s testing confirmed the exploit across 66 loadable vm2 releases, from 0.2.2 through 3.10.4, on Node.js 24.15.0.

We have submitted a PR to improve the advisory on GitHub to correct the affected range and runtime description.

Impact#

vm2 is used by applications that need to evaluate JavaScript in a restricted environment, including code playgrounds, plugin systems, workflow automation tools, development platforms, and other services that execute user-controlled or semi-trusted JavaScript.

Sandbox escape vulnerabilities are serious because they break the isolation boundary the host application depends on. In affected environments, code that was supposed to remain confined to the sandbox can instead interact with the host process and run commands with the same privileges as the application.

The exposure is not the same for every vm2 user. The vulnerability requires attacker-controlled code to reach VM.run() on an affected vm2 version and a Node.js runtime that exposes WebAssembly.JSTag. But where those conditions are present, the impact is critical.

Broader Than the Advisory Indicates#

Socket’s VulnDex page for GHSA-ffh4-j6h5-pg66 now lists 66 affected vm2 versions, spanning 0.2.2 through 3.10.4.

The fix released in vm2 3.10.5 removes WebAssembly.JSTag from the sandbox environment. We found that this mitigation is absent not only from 3.10.4, but from earlier releases as well.

We also confirmed that Node.js 24 exposes WebAssembly.JSTag, meaning the issue is not limited to Node.js 25. The more accurate runtime condition is any Node.js version that exposes WebAssembly.JSTag.

This is an important update because advisory metadata is used by downstream scanners, SCA tools, and dependency management workflows. If the affected range is too narrow, vulnerable deployments may be incorrectly marked as unaffected.

Socket Certified Patches Available#

Socket is releasing free Certified Patches for GHSA-ffh4-j6h5-pg66 so teams can apply a targeted fix without waiting on a full dependency upgrade or dependency tree refactor.

Certified Patches apply a minimal, reviewed change directly to vulnerable package versions while preserving the rest of the package’s behavior.

You can install and apply the patch using:

socket patch add GHSA-ffh4-j6h5-pg66

After installing dependencies, make sure patches are applied as part of your build process.

Individual Certified Patches for Critical and High severity vulnerabilities are free to use and available to anyone, including teams that are not Socket customers.

Teams should also upgrade to vm2 3.10.5 or later where possible, check for transitive vm2 usage, and review whether sandboxed workloads have access to secrets, production credentials, filesystem access, or internal network resources.

Recommended Actions#

Organizations using vm2 should:

• Upgrade to vm2 3.10.5 or later where possible
• Apply Socket’s Certified Patch if a direct upgrade is not immediately practical
• Use Socket to check for direct and transitive usage of affected vm2 versions.
• Identify services that pass untrusted JavaScript to VM.run()
• Confirm whether affected services run on Node.js versions that expose WebAssembly.JSTag
• Run sandboxed workloads with least privilege
• Use stronger isolation, such as separate processes or containers, for untrusted code execution

Given vm2’s history of sandbox escape vulnerabilities, teams that rely on it for untrusted code execution should treat this as both an immediate patching issue and a prompt to review their isolation model.