GHSA-2cm2-m3w5-gp2f

What it actually does

Guest JavaScript running inside the vm2 sandbox can obtain a reference to the host-internal object named VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL. That object is meant to stay hidden from sandboxed code; exposing it leaks host-side handles and breaks isolation, allowing guest code to reach host Node.js capabilities and run arbitrary code in the parent process. Impact is RCE in applications that already evaluate untrusted or attacker-influenced scripts in vm2 (CVSS 5.3).

Why it matters to the business

Products that use vm2 to isolate plugins, user-supplied scripts, or untrusted automation can have that isolation defeated, leading to compromise of the hosting Node.js service, theft of secrets, and abuse of the application's privileges. The issue is not in CISA KEV, has no reported exploit maturity, and is not tied to ransomware, but it has been public for about five months (published 2026-05-08). Any workload still on vm2 before 3.11.2 remains exposed wherever untrusted code is evaluated.

How an attack unfolds

An attacker finds an application that evaluates untrusted JavaScript inside vm2, then submits guest code that reaches the leaked internal-state object instead of staying within the sandbox API. That object is used to obtain host-side constructors, functions, or globals that vm2 was supposed to hide. From the host context the attacker can load modules, spawn processes, read files, or otherwise run code with the privileges of the Node.js process. No named threat actors or ransomware campaigns are associated with this advisory, and public exploit maturity is none; abuse would still follow the same in-process sandbox-escape pattern as prior vm2 isolation failures.

How to fix it

Upgrade the vm2 npm package to 3.11.2 or later in every direct and transitive dependency, then rebuild and redeploy so production actually runs the patched library. There is no reliable configuration-only workaround on 3.11.1 and earlier. Because vm2 has a history of isolation failures, treat in-process sandboxing of truly untrusted code as residual risk even after the upgrade: disable untrusted evaluation where possible, or isolate tenants in a separate process or container.

How to confirm the fix worked

Inventory package-lock.json, yarn.lock, pnpm-lock.yaml, and container images for vm2 versions earlier than 3.11.2, including transitive copies. After upgrade, confirm the resolver reports 3.11.2 or newer and that production artifacts were rebuilt. Review call sites that construct a VM or NodeVM and run guest code to confirm whether untrusted input is still accepted.

Typical attack path

1. Identify a service that evaluates untrusted JavaScript with the vm2 npm package before 3.11.2
2. Submit guest code that obtains the leaked host internal-state object
3. Cross the sandbox boundary into the host Node.js context
4. Perform host-side actions with the privileges of the application process
5. Steal secrets, persist, or move laterally according to the host's role

How to detect it

Exploit maturity is none and no threat actors are named, so hunt for attempts to reach vm2 internals rather than a known malware family. Search application logs, script-submission stores, request bodies, and debug traces for the internal-state identifier. On Node.js hosts that load vm2, look for unexpected child processes, file access outside normal application paths, unusual outbound connections, and unexpected module loads from the sandboxing service around the time untrusted scripts ran. Confirm live processes are not still loading vm2 older than 3.11.2.

• VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL

What your security team should do

• Upgrade every vm2 installation to 3.11.2 or later and redeploy rebuilt artifacts
• Inventory all services that evaluate untrusted or tenant-supplied JavaScript in vm2
• Prefer process- or container-level isolation over an in-process sandbox for untrusted code
• Hunt historical script submissions and logs for the leaked internal-state identifier
• Enforce SCA or lockfile policy that blocks vm2 versions below 3.11.2