Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit malicious JS to vm2 NodeVM sandbox
-
DeliveryReach host __proto__ via console._stdout/_stderr
-
ExploitOverwrite EventEmitter.prototype.emit
-
ExecutionTrigger process event with host context
-
ImpactExecute arbitrary code on host, escaping sandbox
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 | Requires the target application to instantiate a vm2 NodeVM and execute attacker-controlled JavaScript inside it - vm2's core purpose, so within any app that uses vm2 for untrusted code there is no additional barrier. There is no standalone network service; the AV:N reflects that untrusted JavaScript typically arrives over the network to such evaluators. Exploitation is limited to applications still running the deprecated vm2 library at a version before the stated 3.11.8 fix; products not using vm2, or using it only for trusted code, are not affected. No authentication or user interaction beyond getting code into the sandbox is required (PR:N/UI:N per the vendor vector). |
| Impact | This is a genuine maximum-severity issue within its threat model: a NodeVM sandbox escape yielding full host code execution. The vendor CVSS 4.0 is 10.0 (AV:N/AC:L/PR:N/UI:N with all vulnerable- and subsequent-system impacts High), and CWE-913 (improper control of dynamically-managed code resources) fits a prototype-chain reach that overwrites EventEmitter.prototype.emit to run in host process context. However, the raw 10.0 is conditioned on the vm2 threat model: the score is only meaningful for applications that deliberately run attacker-controlled JavaScript inside vm2 NodeVM. There is NO EPSS score, NO CISA KEV listing, and POC status is not confirmed in the input (a proof-of-concept is likely present in the GHSA-88hf-g992-jg85 advisory but this is not stated), so exploitation is 'no public exploit identified at time of analysis'. Net: for any product still using deprecated vm2 (<3.11.8) to sandbox untrusted code, this is a top-priority patch/replace item because escape = total host compromise; for everyone else it is not exploitable. The all-High 4.0 vector with SC/SI/SA:H is defensible here since the escape crosses the sandbox security boundary into the host process, which is a true scope change. One caveat: fix version 3.11.8 does not match vm2's real public history (development ceased around 3.9.19 and the library was deprecated in 2023), so the version metadata should be treated with caution and verified against the vendor advisory. |
| Exploit ScenarioDerived | An application uses vm2 NodeVM to execute untrusted user-supplied JavaScript (e.g. a plugin runner, online code evaluator, or serverless-style function host). Attacker-submitted sandbox code walks from console._stdout/console._stderr to the host __proto__ getter/setter, overwrites EventEmitter.prototype.emit, and triggers a process event to execute code in the host process, escaping the sandbox and gaining full host access. POC availability is not confirmed in the provided data, though advisories for this vm2 wave commonly include one. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
RemediationAI
Upgrade to vm2 3.11.8 or later (vendor-released patch: 3.11.8), the version in which the vendor advisory GHSA-88hf-g992-jg85 fixes the NodeVM escape; verify the resolved version in the lockfile because a vulnerable copy can persist as a transitive dependency. Because the runtime impact is full host code execution, treat any instance that ran untrusted scripts on an older vm2 as potentially compromised and rotate secrets, tokens, and credentials reachable from that process. Longer term, note that vm2 is deprecated and no longer maintained, so plan a migration to a genuinely isolated execution model such as isolated-vm, worker_threads with a restricted resource policy, or a separate low-privilege process/container per evaluation. Where upgrading must be deferred, compensating controls include running the evaluator in a disposable container or microVM with a non-root user, a read-only filesystem, no outbound network, and seccomp/AppArmor confinement (trade-off: added latency and operational complexity, and a container-level escape is still a risk since the host process itself is compromised); removing or shadowing console._stdout and console._stderr in the sandbox context and freezing EventEmitter.prototype.emit before executing untrusted code may break the gadget chain (trade-off: unverified against the full advisory and easily bypassed by other prototype-chain gadgets, so it is not a substitute for patching); and refusing to execute JavaScript from untrusted sources in-process at all (trade-off: loss of the dynamic-evaluation feature).
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 deployed Node.js sandbox designed to execute untrusted JavaScript in-process by proxying host objects and filtering the reachable prototype chains. The NodeVM context exposes a bridged console whose _stdout and _stderr members are proxy references to host stream objects; the escape abuses those bridges to walk back to the host Object.prototype's __proto__ accessor, which should never be reachable from inside a sandbox. With the host prototype chain exposed, the attacker can reassign EventEmitter.prototype.emit, so that when the host process later emits or responds to an event, the poisoned method executes attacker-supplied logic in host context. This is classified CWE-913 (Improper Control of Dynamically-Managed Code Resources), the code-resource-integrity class covering sandboxes that fail to fully isolate dynamically evaluated code - here the escape also defeats vm2's code-generation restrictions, which are intended to block exactly this class of prototype-chain traversal.
Know when Vm2 gets its next vulnerability
- 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
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Untrusted JS in the sandbox is vm2's intended input so PR:N/AC:L; escape crosses the sandbox boundary into the host process (S:C) giving full host code execution (C/I/A:H).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
vm2 before 3.11.8 contains a sandbox escape vulnerability in NodeVM that allows attackers to access the host __proto__ getter/setter through console._stdout and console._stderr. Attackers can overwrite EventEmitter.prototype.emit and trigger process events to execute code with process context, bypassing code generation restrictions.
Technical POC Analysis
The flaw is CWE-913, improper control of dynamically-managed code resources.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
The vm2 JavaScript sandbox library that Node.js services commonly use to run untrusted code safely can be fully escaped, letting attacker-supplied code execute with the complete privileges of the hosting application process. Every customer-facing API, plugin platform, or workflow engine that evaluates network-supplied JavaScript inside a NodeVM instance is exposed, and per the vendor's CVSS:4.0 vector (PR:N, UI:N) no credentials or user interaction are needed once code reaches the evaluator. Because a successful escape means total compromise of that process - its secrets, its internal network position, and its data - leadership should treat this as a potential full-service breach and prioritise eliminating the dependency over waiting for a vendor fix, as no vendor-released patch is identified at time of analysis.
No vendor-released patch identified at time of analysis. Interim mitigations: stop feeding untrusted or network-supplied JavaScript into vm2 NodeVM instances and disable any feature that exposes that evaluator; run any remaining JavaScript evaluation in a separate low-privileged process or container with no access to host secrets, credentials, or the internal network; apply strict egress filtering and least-privilege filesystem and process permissions to the hosting application; monitor for child-process spawning, prototype or EventEmitter tampering, and unexpected outbound connections; rotate secrets accessible to affected processes and plan migration off vm2 in favour of process- or container-level isolation.
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
vm2 is an advanced vm/sandbox for Node.js. Rated critical severity (CVSS 10.0), this vulnerability is remotely exploitab
vm2 is a sandbox that can run untrusted code with Node's built-in modules. Rated critical severity (CVSS 10.0), this vul
vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. Rated critical severity (CVSS 10.
There exists a vulnerability in source code transformer (exception sanitization logic) of vm2 for versions up to 3.9.15,
vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. Rated critical severity (CVSS 10.
This affects the package vm2 before 3.9.4 via a Prototype Pollution attack vector, which can lead to execution of arbitr
Full sandbox escape with arbitrary code execution allows remote attackers to break out of vm2's Node.js sandbox environm
Sandbox escape in vm2 for Node.js allows remote unauthenticated attackers to execute arbitrary commands on the host syst
Sandbox escape in vm2 (patriksimek/vm2) versions prior to 3.11.3 enables remote code execution on the host Node.js proce
Sandbox escape in vm2 Node.js sandbox before 3.10.2 via Promise.prototype.then/catch callback sanitization bypass. PoC a
vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. Rated critical severity (CVSS 9.8
The package vm2 before 3.9.10 are vulnerable to Arbitrary Code Execution due to the usage of prototype lookup for the We
EUVD-2026-81604
GHSA-gg6f-mhqm-f7gp
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB