CVE-2026-92960 in vm2
Summary
by MITRE • 09/17/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in vm2 versions prior to 3.11.6 represents a critical failure in sandbox isolation mechanisms, specifically concerning the handling of built-in Node.js modules when configured with wildcard access permissions. In typical usage scenarios where developers grant broad access to internal modules using the builtin: ['*'] configuration, the library fails to adequately restrict execution context boundaries for sensitive system-level APIs such as os and dns. This oversight allows sandboxed code to escape its isolated environment and interact directly with host process internals that should remain inaccessible to untrusted or semi-trusted scripts. The core technical flaw lies in the insufficient filtering of method calls within these built-in modules, permitting operations that have side effects on the global state of the Node.js runtime rather than remaining confined to the sandboxed execution context.
From a technical perspective, this vulnerability enables attackers to manipulate critical system functions through specific API endpoints exposed by the vulnerable built-ins. Most notably, the dns.setServers() method can be invoked from within the sandbox to reconfigure the DNS resolver used by the entire host process. This is not an isolated change limited to the sandbox; instead, it alters global configuration parameters that affect all subsequent network resolution requests made by the application. By redirecting DNS queries through a server controlled by the attacker, malicious actors can perform man-in-the-middle attacks on domain name resolutions, potentially leading to data exfiltration, credential theft via phishing redirects, or further exploitation of downstream services relying on accurate host identity verification.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and lateral movement within an application ecosystem. Beyond DNS hijacking, the ability to access os built-ins allows attackers to read sensitive information about the host process identity and network topology. This includes details such as hostname, IP addresses, operating system type, and memory usage statistics, which can be leveraged by threat actors to map out the internal infrastructure of a target organization. Such reconnaissance activities facilitate more targeted attacks against other systems within the same network segment or cloud environment, significantly increasing the blast radius of an initial compromise involving untrusted JavaScript execution.
This flaw aligns with CWE-250, which describes Execution Beyond Protected Boundaries, as it allows code to execute operations outside its designated security context. Furthermore, in terms of the MITRE ATT&CK framework, this vulnerability supports techniques associated with Discovery and Command and Control, specifically allowing adversaries to gather system information and manipulate network communication channels for covert data transfer or command routing. The ability to modify global DNS settings is particularly dangerous as it undermines trust assumptions inherent in secure application design, where sandboxed code should never have the authority to alter shared resources that impact other parts of the application stack.
To mitigate this risk, organizations must immediately upgrade vm2 to version 3.11.6 or later, where these access control restrictions have been implemented and validated. For environments unable to update promptly due to dependency constraints, it is advisable to avoid using the builtin: ['*'] configuration with untrusted input sources. Instead, developers should adopt a whitelist approach by explicitly specifying only those built-in modules that are strictly necessary for application functionality while excluding sensitive ones like dns and os from sandbox access lists. Additionally, implementing strict Content Security Policies and monitoring network traffic anomalies can help detect potential exploitation attempts involving unexpected DNS resolution patterns or unauthorized system information queries during runtime operations.