Skip to content
eastbaycyber

CVE-2026-47131: Critical Sandbox Escape in vm2

CVSS · Critical
10.0
In CISA KEV
No
Published
Jun 12
Patch SLA & TriageVector: Local
24 to 48 hours

Critical CVSS (10.0) reachable over local.

Exposure:
Control:
CVE explainers 8 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-06-12
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief
Field Value
CVE ID CVE-2026-47131
CVSS score 10.0 Critical
Attack vector Sandbox escape leading to arbitrary code execution
Auth required Unknown from cited sources; defenders should assume reachable untrusted code execution is sufficient
Patch status Fixed in vm2 3.11.4

TL;DR - vm2 versions prior to 3.11.4 contain a critical sandbox escape. - Any app executing untrusted JavaScript with vm2 is affected. - Upgrade immediately and treat exposed hosts as potentially compromised.

Vulnerability at a Glance

CVE-2026-47131 is a critical vulnerability in vm2, the popular Node.js sandbox library maintained in the patriksimek/vm2 project. According to the NVD, the issue allows a sandbox escape that can lead to arbitrary code execution on the host. The NVD assigns a CVSS v3.1 score of 10.0, placing this bug in the highest severity tier.

The affected version range is clearly stated: all vm2 versions prior to 3.11.4 are vulnerable, and the issue is patched in version 3.11.4. That version boundary matters for defenders because many applications pin npm dependencies indirectly. Even if your application code does not import vm2 directly, a plugin framework, automation platform, or user-code execution feature may bring it into the environment through transitive dependencies.

What This Vulnerability Is

At a high level, this is a sandbox breakout. vm2 is designed to let developers run JavaScript that should be isolated from the host Node.js process. CVE-2026-47131 breaks that trust boundary. If an attacker can supply code to a vulnerable vm2 instance, they may be able to escape the sandbox and execute code in the host runtime instead of the restricted guest context.

The NVD description is unusually specific about the exploit path. It says the issue can be triggered by combining Buffer.call.call({}.__lookupGetter__, Buffer, "__proto__"), Buffer.call.call({}.__lookupSetter__, Buffer, "__proto__"), and Node.js ERR_INVALID_ARG_TYPE error behavior. The resulting effect is access to the host’s TypeError constructor, which then enables escape from the sandbox. For practitioners, the important point is not the exact JavaScript trick so much as the impact: code intended to stay confined may gain host-level execution within the Node.js service process.

Technical Notes

// NVD-described exploit primitives involved in the bypass path
Buffer.call.call({}.__lookupGetter__, Buffer, "__proto__");
Buffer.call.call({}.__lookupSetter__, Buffer, "__proto__");
// Combined with Node.js ERR_INVALID_ARG_TYPE behavior
// to obtain the host TypeError constructor

Impact chain:
untrusted JS -> vm2 sandbox -> host TypeError constructor access -> sandbox escape -> arbitrary code execution
AnalystImpact · assess the risk

Who Is Affected

The vulnerable product is vm2, an open-source sandbox for Node.js distributed through the npm ecosystem. The affected versions are all versions prior to 3.11.4. The fixed version is 3.11.4. Those version details come directly from the NVD entry and are reinforced by the linked v3.11.4 release and fix commit in the upstream repository.

In practical terms, organizations are affected if they run any feature that executes tenant-controlled, user-supplied, or otherwise untrusted JavaScript using vm2. Common examples include online code runners, plugin systems, workflow automation, low-code platforms, embedded scripting in SaaS products, and custom policy or transformation engines. If your business relies on vm2 as a security boundary, you should assume this issue undermines that boundary completely.

Technical Notes

To identify direct usage in a project:

npm ls vm2

To identify the resolved version in projects using lockfiles:

grep -R "vm2" package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml

To inspect the installed version locally:

node -e "console.log(require('vm2/package.json').version)"

To locate vm2 across container images or hosts:

find / -type f \( -name package.json -o -name package-lock.json -o -name yarn.lock -o -name pnpm-lock.yaml \) 2>/dev/null | xargs grep -H "\"vm2\""

CVSS Score and Severity Context

The NVD assigns CVSS v3.1 10.0 Critical to CVE-2026-47131. The compact data available in the research note did not include the vector string, so it would be inaccurate to restate a full vector here. When the vector is unavailable from your source of truth, defenders should avoid guesswork and work from the confirmed impact instead: sandbox escape plus arbitrary code execution.

A 10.0 score is operationally significant because vm2 is often deployed precisely to reduce the risk of running hostile code. When the isolation mechanism itself fails, the issue can collapse multiple control assumptions at once. Depending on the runtime privileges of the Node.js service, a successful escape may expose secrets, application data, filesystem contents, service account credentials, and internal network reachability.

Exploitation Status

As of 2026-06-12, CISA KEV does not list CVE-2026-47131, so there is no official KEV confirmation of exploitation in the wild based on the sources provided. That is useful context, but it should not be interpreted as safety. KEV is not exhaustive, and many critical vulnerabilities are exploited before appearing in public government tracking.

A separate standalone public PoC repository was not confirmed from the sources in this task. However, the NVD description itself includes concrete exploitation primitives and the high-level mechanism of the bypass. That means defenders should treat this as having public technical exploit detail, even if a turnkey exploit repository has not been verified. In short: in-the-wild exploitation is not confirmed, a dedicated PoC is not confirmed, but enough exploit detail is public to raise urgency.

What Defenders Should Do Next

Start with a quick scoping exercise across repositories, build pipelines, containers, and production nodes to find every instance of vm2. Prioritize systems that execute customer-controlled or tenant-controlled JavaScript, especially if they are internet-facing. If any deployment resolves to a version before 3.11.4, move it into your emergency patch queue.

After patching, decide whether you need incident response actions. If the vulnerable service processed untrusted code before remediation, consider reviewing logs for suspicious child processes, outbound connections, and unusual file access. Also assess what secrets the Node.js process could reach, and rotate those credentials where justified. Because confirmed in-the-wild exploitation is not currently known from the cited sources, defenders need to balance urgency with evidence. The safe operational assumption is this: if an attacker could submit code to a vulnerable vm2 sandbox, compromise was possible, and patching alone may not close the full risk.

ResponderRunbook · act now

How to Detect Exposure and Potential Abuse

The first detection step is inventory: determine where vm2 is installed and whether the resolved version is earlier than 3.11.4. Because vm2 is an npm package, this often means checking CI manifests, lockfiles, built containers, and production application directories. If your software supply chain allows transitive dependency drift, you should verify the effective deployed version rather than trust source repositories alone.

The second detection step is behavioral review. A successful sandbox escape may not produce a neat CVE-2026-47131 indicator in logs. Instead, look for abnormal events in services that run untrusted JavaScript: unexpected child process creation, network egress from the Node.js service, filesystem reads outside intended working directories, or error messages involving invalid argument types during code execution. Because the NVD references ERR_INVALID_ARG_TYPE as part of the chain, logs containing that error around sandbox execution may be worth triaging, though they are not proof of exploitation by themselves.

Technical Notes

Example dependency/version checks in CI or on a host:

npm ls vm2 --all
node -p "require('vm2/package.json').version"

Example application log patterns to review:

ERR_INVALID_ARG_TYPE
TypeError
__lookupGetter__
__lookupSetter__
Buffer.call.call

Example Splunk query for Node.js application logs where sandbox jobs run:

index=app_logs sourcetype=nodejs ("ERR_INVALID_ARG_TYPE" OR "__lookupGetter__" OR "__lookupSetter__" OR "Buffer.call.call")
| stats count by host, app, message

Example Elasticsearch / Kibana KQL:

message:("ERR_INVALID_ARG_TYPE" or "__lookupGetter__" or "__lookupSetter__" or "Buffer.call.call")

Example EDR hunting idea on Linux hosts running Node.js:

Parent process: node
Child processes of interest: sh, bash, curl, wget, python, nc

If you lack detailed application logs, assume absence of evidence is not evidence of absence. For internet-facing or multi-tenant services that accepted untrusted JavaScript while running vulnerable vm2 versions, it is prudent to perform a compromise assessment after patching.

Mitigation and Patching

The primary remediation is straightforward: upgrade vm2 to version 3.11.4 or later. The fixed version is explicitly identified in the NVD and upstream release reference. If vm2 is a direct dependency, update it in your package manifest and rebuild. If it is transitive, update the parent dependency or use the package manager features available in your environment to force resolution to a safe version, then test carefully.

If you cannot patch immediately, reduce exposure by disabling features that execute untrusted code, isolating the service at the container or VM level, restricting outbound network access, and lowering process privileges. These workarounds do not fix the bug, but they can reduce blast radius if exploitation occurs. Because this is a sandbox escape, it is wise to assume the sandbox itself is not a reliable security boundary until patched.

Technical Notes

Direct npm upgrade:

npm install [email protected] --save

If using Yarn:

yarn add [email protected]

If using pnpm:

pnpm add [email protected]

To verify the installed version after upgrade:

node -e "console.log(require('vm2/package.json').version)"

Example package.json pin:

{
  "dependencies": {
    "vm2": "3.11.4"
  }
}

If vm2 is transitive and you use npm overrides:

{
  "overrides": {
    "vm2": "3.11.4"
  }
}

Temporary risk-reduction controls if upgrade is blocked:

- Disable user-supplied script execution paths
- Run the Node.js service as a non-privileged account
- Deny unnecessary egress from the service container or host
- Separate the workload into a dedicated container or VM
- Rotate credentials accessible to the process if exposure is suspected

References

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-06-12

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.