GHSA-q3fm-4wcw-g57x

What it actually does

A flaw in vm2's setup-sandbox.js stack-trace formatter violates a core sandbox isolation invariant (Defense Invariant #11). Untrusted JavaScript executed inside the vm2 sandbox can abuse Error stack-trace handling to obtain host-realm objects or privileged functions, fully escaping the sandbox and executing arbitrary code in the host Node.js process (RCE with the privileges of the application).

Why it matters to the business

Any product that runs customer, plugin, or otherwise untrusted JavaScript inside vm2 can lose that isolation entirely, exposing application secrets, data stores, cloud credentials, and the host. Impact is process-level compromise, service outage, and potential supply-chain or multi-tenant blast radius wherever vm2 is a dependency. The issue is about four months old, is not listed in CISA KEV, and has no reported in-the-wild exploit maturity, but it is still a sandbox-escape RCE and should be treated as a high-priority patch for any internet-facing or multi-tenant workload that evaluates untrusted code.

How an attack unfolds

An attacker who can submit JavaScript that the application evaluates inside vm2 crafts guest code that forces the sandbox's stack-trace formatter down the vulnerable path in setup-sandbox.js. That path leaks a host object or callable out of the sandbox. The attacker then uses the leaked primitive to reach Node.js host APIs (module loading, filesystem, child processes, or network) and run arbitrary code as the application user. No separate network exploit is required beyond whatever channel already feeds code into vm2 (user scripts, templates, plugins, CI tasks, or similar).

How to fix it

Upgrade the vm2 npm package to 3.11.4 or later everywhere it is declared or pulled in transitively (package.json, lockfiles, container images, and bundled vendor trees). Rebuild and redeploy all artifacts so no process still loads an older vm2. Because vm2 has a long history of sandbox-escape RCEs, treat the version bump as an interim control and plan migration off vm2 for any workload that must run untrusted JavaScript (for example, a maintained isolate/worker design that does not share the host realm). Until upgraded, do not evaluate untrusted JavaScript in vm2; restrict evaluation to fully trusted code only.

How to confirm the fix worked

Inventory every package lock and image: npm ls vm2 (and equivalent yarn/pnpm/bundler queries) and fail the build if any installed copy is older than 3.11.4. Confirm runtime processes load the patched module (resolved path under node_modules/vm2 and the 3.11.4 version in npm metadata). After deploy, regression-test the sandbox entrypoints with trusted fixtures only—do not attempt exploit reproduction. Re-scan SBOMs and container layers to ensure no stale transitive copy remains.

Typical attack path

1. Identify an application or service that executes untrusted or user-controlled JavaScript inside the vm2 sandbox.
2. Deliver crafted guest JavaScript through the existing evaluation channel (upload, API, plugin, template, or similar).
3. Trigger the vulnerable stack-trace formatter in setup-sandbox.js so a host-realm object or function crosses the sandbox boundary.
4. Use the leaked host primitive to invoke Node.js APIs outside the sandbox.
5. Execute follow-on actions on the host process: read secrets, write files, spawn processes, or open outbound connections.
6. Optionally persist or move laterally using the compromised Node.js process identity.

How to detect it

There is no public exploit maturity and no named threat actors for this issue, so confirmed in-the-wild use is not expected by default; hunt for sandbox-escape aftermath rather than a unique payload. Review application logs around script-evaluation APIs for unexpected host errors, stack traces that mention setup-sandbox.js or prepareStackTrace, or guest scripts that suddenly succeed in filesystem, child_process, or network operations. On hosts that run vm2, inspect Node.js process trees for unexpected child processes, outbound connections, or file writes immediately after user-script execution. Compare running module versions against 3.11.4; a still-vulnerable copy plus anomalous host activity after a script run is the strongest exposure-plus-exploitation signal. Preserve guest-script audit logs if the product records submitted code.

• node_modules/vm2/lib/setup-sandbox.js
• "vm2": "3.11.3"
• "vm2": "3.11.2"
• "vm2": "3.11.1"
• "vm2": "3.11.0"
• "vm2": "3.10.
• "vm2": "3.9.
• Error.prepareStackTrace

What your security team should do

• Patch vm2 to 3.11.4 or later in all direct and transitive dependencies and redeploy immediately for any service that evaluates untrusted JavaScript.
• Block or quarantine untrusted script evaluation until patched builds are confirmed in production.
• Inventory npm/yarn/pnpm lockfiles, container SBOMs, and serverless bundles for vm2 < 3.11.4 and track to closure.
• Plan migration away from vm2 for untrusted-code use cases given repeated sandbox-escape failures in this family.
• Prioritize internet-facing and multi-tenant script hosts first; then internal automation that still runs third-party JS in-process.