EUVD-2026-81610
GHSA-qj2x-7x9q-qgm7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit JS to vm2 sandbox (builtin:['*'])
-
DeliveryInvoke os.userInfo/networkInterfaces
-
ExploitRead host identity + network topology
-
ExecutionCall dns.setServers to attacker resolver
-
ImpactHijack all host DNS globally
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V14 - Data Protection Data exposure prevention
MITRE ATT&CK
2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the application to (1) run attacker-controlled JavaScript inside vm2's NodeVM - the tool's core threat model - and (2) be configured with the NON-default builtin: ['*'] setting, which exposes the os and dns builtins the fix should have blocked. No user interaction or authentication is needed once code reaches the sandbox. Exploitation is LIMITED to deployments below 3.11.6 that both accept untrusted code and use the wildcard builtin whitelist; default or restricted builtin configurations are not affected. The dns.setServers() write is process-wide and persists for the life of the host process. |
| Impact | This is a genuinely high-severity issue within its threat model, but its real-world priority is gated by a non-default configuration and vm2's inherent purpose. The vendor scores CVSS 4.0 10.0 and the GHSA gives CVSS 3.1 9.3 (S:C/C:H/I:H/A:L); both are defensible because the read data (host UID/GID/username/homedir via os.userInfo, full network topology via os.networkInterfaces) and the written state (dns.setServers hijacking every subsequent host DNS lookup) belong to the host process, not the sandbox - a legitimate Scope=Changed. PR:N is justified only because the attacker is assumed to control sandbox code, which is precisely what NodeVM exists to contain, so within vm2's model there is no auth barrier. However, two signals temper urgency: exploitation requires the NON-default builtin: ['*'] configuration, and there is no EPSS score, no CISA KEV listing, and no standalone weaponized exploit - only advisory-level technical detail. No signals conflict, but the raw 10.0 overstates blast radius for the typical deployment that does not enable builtin: ['*']. Note the affected library (vm2) has been deprecated/unmaintained since 2023, so patched adoption is uncertain even though 3.11.6 exists. |
| Exploit ScenarioDerived | An application uses vm2's NodeVM to run untrusted user-supplied JavaScript and has enabled builtin: ['*']. The attacker submits sandbox code that calls os.userInfo() and os.networkInterfaces() to exfiltrate host identity and internal network topology, then calls dns.setServers() pointing at an attacker-controlled resolver, silently redirecting all subsequent host DNS queries (outbound HTTP, telemetry, npm/registry) for interception or redirection. No standalone public exploit is identified beyond the technical detail in the GHSA advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
Sandboxed JavaScript executed inside vm2's NodeVM before 3.11.6 can step outside the isolation boundary to read host process identity and network topology and, worse, to hijack the host's DNS resolver process-wide. The exposure is gated by two conditions: the embedding application must run attacker-controlled code in NodeVM (the tool's core threat model) and must use the non-default wildcard whitelist builtin: ['*'], which fails to exclude the os and dns modules; the assessed vector is unauthenticated (CVSS PR:N), so once code reaches the sandbox no credentials or user interaction are needed, and a single dns.setServers() call persists for the life of the host process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released patch is vm2 3.11.6. Real-world priority is driven less by raw severity than by whether a deployment both accepts untrusted code and enables the wildcard builtin list.
RemediationAI
Upgrade to the vendor-released patch: vm2 3.11.6, which closes the os and dns gap alongside the earlier GHSA-9g8x-92q2-p28f builtin blocklist changes (see https://github.com/patriksimek/vm2/security/advisories/GHSA-m5w8-4gq2-6f8x). If upgrading is not immediately possible, the most effective compensating control is configuration-side and low-risk: stop using builtin: ['*'] and supply an explicit allowlist of only the modules the sandboxed code genuinely needs, explicitly omitting os and dns - the trade-off is that legitimate sandbox code relying on those modules breaks, which is the desired outcome in an untrusted-code context. Do not rely on vm.readonly() wrappers around os or dns as a mitigation, since the advisory states the readonly proxy forwards calls to host state and remains a working exfiltration and mutation primitive. Where untrusted code must run, additionally sandbox the Node.js process itself (container or VM with a restricted resolver configuration) so that a successful dns.setServers() call cannot reach the host resolver, at the cost of added operational complexity. After patching, rotate or review any credentials and DNS-dependent trust relationships if the deployment ran untrusted code with the wildcard builtin, since host identity and network topology may already have been disclosed and outbound DNS may have been redirected.
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 Node.js sandbox library whose NodeVM API lets embedders execute untrusted JavaScript while restricting which Node builtin modules that code can require; the intended control point is the builtin option, where an explicit allowlist is the safe configuration. Per the upstream advisory (GHSA-m5w8-4gq2-6f8x), an earlier fix (GHSA-9g8x-92q2-p28f / Category 35 in docs/ATTACKS.md) added diagnostics_channel, async_hooks, perf_hooks, and v8 to DANGEROUS_BUILTINS in lib/builtin.js because those modules surface host-process state that the vm2 boundary cannot localise - a readonly proxy forwarding calls to the host module is itself a host-data exfiltration primitive. The same reasoning was not applied to os and dns, which remain reachable under builtin: ['*']. Reads include os.userInfo() (host UID/GID, username, home directory) and os.networkInterfaces() (full host network topology, including container/VM interfaces with IP and MAC addresses); writes include os.setPriority(), dns.setDefaultResultOrder(), and critically dns.setServers(), a process-global mutation that reroutes every subsequent host DNS lookup - outbound HTTP, telemetry, npm/registry traffic, and any host code resolving names via fetch or URL-based filesystem paths - through an attacker-chosen resolver. The root cause is an incorrect permission assignment / improper authorization for a critical shared resource, captured by the CNA as CWE-200 with the advisory chaining CWE-732 and CWE-285; the assessed CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L (9.3) marks scope as Changed precisely because both the disclosed data and the mutated state belong to the host process rather than the sandbox. Note the severity discrepancy between the supplied CVSS 4.0 score of 10.0 and the independent v3.1 assessment of 9.3; the lower Availability component (A:L) and the non-default configuration requirement make 10.0 an overstatement of practical risk.
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:L/SC:H/SI:H/SA:L
Attacker controls sandbox code (PR:N under vm2's model); reads/writes host-process state gives S:C, C:H (identity+topology) and I:H (global DNS hijack); A:L for resolver disruption/setPriority.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
vm2 before 3.11.6 fails to restrict access to os and dns builtins under the builtin: ['*'] configuration, allowing sandbox code to read host process identity and network topology. Attackers can invoke dns.setServers() to hijack the host process DNS resolver globally, redirecting all subsequent host DNS queries through an attacker-controlled resolver.
Blast Radius
ecosystem impact- 18 npm packages depend on vm2 (6 direct, 12 indirect)
Ecosystem-wide dependent count for version 3.11.6.
Technical POC Analysis
The bug is an incomplete denylist in vm2's builtin gating logic, not a flaw in Node's os or dns modules themselves.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
vm2, a widely used JavaScript sandbox, contains a critical flaw (CVE-2026-92960) that allows untrusted code to escape isolation and hijack host DNS resolution process-wide. Organizations that execute third-party or user-supplied code within vm2 using the wildcard builtin list are at risk of full host compromise, affecting all tenants and services on that host. Leadership should prioritize immediate patching to vm2 3.11.6 and verify that no deployments rely on the insecure configuration.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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
Exploit-DB