CVE-2026-93603: vm2 Sandbox Escape
TL;DR - CVE-2026-93603 is a critical vm2 sandbox-escape flaw affecting versions through 3.12.0. - Applications that expose non-strict host functions to sandboxed JavaScript are at risk of host command execution. - Upgrade to vm2 3.12.1 or later and investigate affected workloads if untrusted code executed before patching.
CVE-2026-93603 is a critical vm2 sandbox escape vulnerability affecting applications that use the vm2 JavaScript sandbox library to run untrusted code. Under specific conditions, sandboxed JavaScript can access the host global object and execute operating-system commands through the Node.js process.
Vulnerability at a Glance
CVE-2026-93603 affects the vm2 JavaScript sandbox library. The issue is in the bridge implementation used to mediate objects and function calls between sandboxed code and the host Node.js process. Under the vulnerable condition, sandboxed code can obtain access to the host global object and use it to execute operating-system commands.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-93603 |
| Product | vm2 JavaScript sandbox library |
| Affected versions | Through 3.12.0 |
| Fixed version | 3.12.1 |
| CVSS base score | 10.0, Critical |
| CVSS vector | Not included in the supplied NVD data |
| Attack vector | Not specified in the supplied CVSS data; exploitation requires code execution inside an affected vm2 context |
| Authentication required | Not specified in the supplied CVSS data |
| Patch available | Yes |
| CISA KEV status | Not listed as of 2026-09-18 |
The practical risk depends on how the embedding application uses vm2. A deployment that never executes attacker-controlled JavaScript or never exposes host functions may not meet the exploitation precondition. However, applications that run untrusted, user-supplied, plugin-provided, or AI-generated JavaScript should treat this as a host-level remote-code-execution risk.
What Is This Vulnerability?
The root cause is improper handling of a nullish this receiver in the apply trap of vm2’s bridge implementation in lib/bridge.js. When sandboxed code calls an exposed, non-strict host function without a receiver, the undefined receiver can pass through to the host call. V8 then applies JavaScript’s non-strict this semantics and substitutes the host realm’s global object.
Examples of calls that can create the relevant condition include fn(), a detached method call, fn.call(), fn.apply(undefined), Reflect.apply(fn, undefined, []), and fn.bind()(). The specific exploitability depends on whether the host function exposed to the sandbox is non-strict. Strict-mode functions and ECMAScript-module host functions are not affected by this specific behavior.
The bridge subsequently wraps and returns the host global object to sandboxed code. That defeats the isolation boundary because the returned object can provide a path to the host Node.js runtime, including process. The vulnerability description identifies process.getBuiltinModule('child_process').execSync as an example route to command execution.
A successful exploit can therefore escape the JavaScript sandbox, access host-process data and credentials, execute arbitrary commands, and reach infrastructure available to the Node.js process. This is more serious than ordinary code execution confined to a JavaScript context because the affected boundary is intended to separate untrusted code from the host.
Who Is Affected?
The affected product is the vm2 npm package through and including version 3.12.0. The fixed release is 3.12.1. The relevant ecosystem consists of Node.js applications that embed vm2 through VM, NodeVM, or related application wrappers and then execute attacker-influenced JavaScript.
Particularly important deployment scenarios include code-execution services, plugin platforms, automation systems, workflow engines, server-side templating systems, and AI-agent or LLM-generated JavaScript environments. These systems should be reviewed for both package version and host-function exposure. Merely having vm2 installed is not enough to establish exploitability, but it is sufficient to trigger an inventory and upgrade requirement.
The exploitation precondition is specific: the embedding application must expose at least one non-strict host function to sandboxed code. Applications should inventory callbacks, helper functions, APIs, and object methods injected into a VM or NodeVM context. A function can be exposed indirectly through an object property, so reviewing only top-level globals may miss the risk.
Organizations should also review their broader software supply chain attack exposure when vm2 is installed transitively or bundled into third-party application components.
CVSS Score Breakdown
The supplied NVD information reports a CVSS base score of 10.0, rated Critical, but does not provide a CVSS vector string. As a result, the individual metric values for attack vector, attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability cannot be stated reliably from the available record.
Operationally, the vulnerability has high impact because a successful sandbox escape can result in arbitrary command execution by the host Node.js process. That can affect application data, secrets, credentials, local files, connected services, and infrastructure reachable from the host. The exploit still requires the application to run attacker-influenced JavaScript in vm2 and to expose a suitable non-strict host function.
Defenders should not infer that the missing vector means the issue is low risk. In the absence of a published vector, use the deployment’s actual exposure to prioritize remediation: internet-facing code execution, multi-tenant services, plugin systems, and systems processing untrusted automation should receive urgent attention.
Exploitation Status
Public vulnerability details are available through the maintainer-hosted GitHub Security Advisory and additional vulnerability research. Those references describe the vulnerable version range, the nullish receiver condition, the sandbox escape impact, and the 3.12.1 remediation release.
A separate public exploit repository was not verified in the supplied research. The available advisory material documents the exploitation condition and command-execution path, so defenders should not assume that the absence of a standalone exploit repository makes exploitation impractical.
CVE-2026-93603 is not currently listed in the CISA Known Exploited Vulnerabilities catalog. Therefore, there is no CISA confirmation of exploitation in the wild, no KEV remediation deadline, and no CISA-confirmed ransomware campaign associated with this CVE as of 2026-09-18. This status can change, and KEV absence is not evidence that a vulnerable deployment is safe.
How to Detect It
Begin by identifying every installed vm2 version, including transitive dependencies and separate application bundles. Package-lock files, container images, build artifacts, and runtime filesystem inspection should all be checked because production versions can differ from the versions declared in source repositories.
npm ls vm2 --all
npm explain vm2
grep -R '"vm2"' package.json package-lock.json npm-shrinkwrap.json 2>/dev/null
The following query is useful for locating likely host-function exposure patterns. It is an inventory aid, not proof of exploitability. Review each match to determine whether the function or object is made available to untrusted sandbox code.
grep -RInE \
'new[[:space:]]+(VM|NodeVM)|require\(["'\''']vm2|from[[:space:]]+["'\''']vm2|sandbox[[:space:]]*:|global[[:space:]]*:|require[[:space:]]*:' \
--include='*.js' --include='*.mjs' --include='*.cjs' --include='*.ts' .
Technical Notes
CVE-2026-93603 does not necessarily produce a distinctive application log entry. Detection should therefore combine dependency inventory, source review, runtime telemetry, and host-process monitoring. In particular, investigate child processes launched by Node.js services that normally should not spawn shells or operating-system utilities.
Example Linux audit rules can capture process execution by a known Node.js service account. Replace the account and executable paths with values appropriate to the environment:
sudo auditctl -a always,exit -F arch=b64 -S execve \
-F auid=nodeapp -k node-child-process
sudo ausearch -k node-child-process -i
Useful investigation patterns include Node.js processes spawning /bin/sh, sh, bash, curl, wget, python, perl, or package-management tools, especially when the parent process is an application that executes user- or agent-supplied JavaScript. These patterns are not proof of exploitation, but they are high-value triage signals when correlated with requests that triggered sandbox execution.
Mitigation and Patching
Upgrade vm2 to version 3.12.1 or later. Pinning the fixed version first provides a deterministic remediation, after which the application can adopt a later compatible release through its normal dependency-management process.
npm install [email protected] --save-exact
npm audit
npm test
For a lockfile-based deployment, update the dependency and regenerate the lockfile in a controlled build environment, then rebuild and redeploy all affected application images. Confirm the deployed version rather than relying only on source changes:
npm ls vm2
node -p "require('vm2/package.json').version"
If immediate upgrading is impossible, stop exposing non-strict host functions to sandboxed code. Review all callbacks, methods, helper objects, and globals passed into VM or NodeVM contexts. Prefer strict-mode functions and ECMAScript modules where operationally feasible, but treat this as a temporary risk reduction rather than a replacement for upgrading.
"use strict";
const safeHelper = function safeHelper(value) {
return String(value);
};
This workaround does not address every possible sandbox weakness and should not be treated as a complete security boundary. For high-risk or multi-tenant workloads, move untrusted execution into a separate process, container, or stronger isolation mechanism with least-privilege credentials, restricted network access, read-only filesystems where possible, and resource limits.
If untrusted code may have run against vm2 through 3.12.0, treat the host as potentially exposed. Review child-process activity, outbound connections, file access, environment-variable exposure, and application credentials. Rotate secrets available to the Node.js process and investigate adjacent systems if suspicious activity is found. A password manager such as Try 1Password → can help teams rotate and centrally manage replacement credentials during remediation.
Technical Notes
A basic emergency control is to fail deployment when a vulnerable version is present:
test "$(node -p "require('vm2/package.json').version")" = "3.12.1" \
|| { echo "vm2 must be upgraded to 3.12.1 or later"; exit 1; }
Because the check above accepts only the fixed version, adapt it for later approved versions or use a package-policy tool that enforces a minimum semantic version. Also verify transitive installations with npm ls vm2 --all; an application can contain more than one package copy if dependency resolution or bundled assets are inconsistent.
Incident Response Checklist
If a vulnerable application executed untrusted JavaScript before patching:
- Upgrade
vm2to 3.12.1 or later. - Identify all affected hosts, containers, bundles, and lockfiles.
- Review Node.js child-process creation and shell execution.
- Check outbound connections, file access, and environment-variable reads.
- Rotate credentials and tokens available to the affected process.
- Review neighboring systems reachable through application credentials or network access.
- Preserve relevant logs and runtime artifacts before rebuilding or deleting affected hosts.
- Document whether exposed functions were non-strict and whether attacker-controlled code was processed.
References
The maintainer-hosted GitHub Security Advisory is the primary source for the affected range and remediation version:
The NVD record provides the CVE identification and severity information:
Additional technical context on the sandbox escape and command-execution impact is available from Vulnerability Research:
CISA’s Known Exploited Vulnerabilities catalog should be checked during triage and remediation tracking. The supplied lookup indicates that CVE-2026-93603 was not listed as of 2026-09-18:
For background on identity and access risks that can compound a host compromise, see the IDOR glossary.
The most defensible remediation decision is to upgrade all affected deployments to vm2 3.12.1 or later, remove unnecessary host-function exposure, and use stronger process or container isolation for workloads that execute untrusted JavaScript.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.