CVE-2026-92963 in vm2
Summary
by MITRE • 09/17/2026
vm2 versions before 3.11.2 fail to properly restrict access to the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL global variable. Attackers can access this internal state object through globalThis to retrieve sensitive sandbox internals.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in vm2 prior to version 3.11.2 represents a critical failure in the isolation mechanisms designed to protect Node.js virtual machines from untrusted code execution. The core issue stems from an improper restriction of access to internal state variables, specifically targeting the global variable named VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL. This identifier is explicitly marked with instructions indicating that it should not be accessed directly by external programs because doing so compromises the integrity and stability of the virtual machine environment. By failing to properly restrict access to this specific object through the globalThis context, vm2 allows sandboxed code to reach into the host's internal state, effectively breaking the security boundary between the untrusted execution context and the underlying runtime infrastructure.
From a technical perspective, the flaw exploits how JavaScript handles global scope resolution within virtualized environments. In Node.js, the globalThis object serves as the universal global object, providing access to various built-in objects and properties regardless of whether code is running in a browser or server-side environment. The vulnerability arises because vm2 did not sufficiently sandbox this specific internal state variable when creating isolated contexts. An attacker executing malicious code within the vulnerable vm2 instance can traverse up from their local scope to globalThis, locate the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL object, and inspect or modify its contents. This access grants the attacker visibility into sensitive sandbox internals that are intended to remain opaque to external processes, thereby undermining the fundamental purpose of using a virtual machine for security isolation.
The operational impact of this vulnerability is severe, as it enables potential remote code execution and data exfiltration scenarios in applications relying on vm2 for safe script evaluation. Once an attacker gains access to these internal states, they can potentially manipulate the sandbox's configuration, escape the restricted environment, or execute arbitrary commands with the privileges of the host process. This level of compromise is particularly dangerous in server-side JavaScript environments where untrusted user input might be processed through dynamic code execution features. The ability to retrieve sensitive internals means that attackers could extract cryptographic keys, session tokens, or other confidential data stored within the sandbox's memory space, leading to significant confidentiality and integrity breaches for the hosting application.
This vulnerability aligns with CWE-284, which describes Improper Access Control, as it involves a failure to enforce proper restrictions on access to critical system resources. Furthermore, in the context of the MITRE ATT&CK framework, this flaw facilitates techniques related to Defense Evasion and Privilege Escalation by allowing an attacker to bypass intended security boundaries within the application runtime. The exploitation path typically falls under lateral movement or initial compromise vectors where sandbox escape is a prerequisite for deeper system access. Developers must recognize that relying on internal state variables without robust isolation mechanisms creates a significant attack surface in dynamic code execution scenarios.
To mitigate this risk, organizations and developers should immediately upgrade to vm2 version 3.11.2 or later, where the maintainers have implemented stricter controls over global scope access and specifically restricted visibility of the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL variable. In addition to upgrading dependencies, it is advisable to review any custom configurations that might expose additional internal APIs through sandboxed contexts. Implementing strict Content Security Policies for JavaScript execution environments and minimizing the use of dynamic code evaluation where possible can further reduce exposure. Regular security audits focusing on how third-party libraries handle isolation boundaries are essential to prevent similar vulnerabilities in other components of the software stack.