CVE-2026-92939 in vm2
Summary
by MITRE • 09/17/2026
vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority. Sandboxed JavaScript can therefore call crypto.setEngine() with a filesystem path to an attacker-supplied native library (for example, one bundled in an untrusted plugin package already written to disk); OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and does not require fs, process, module, child_process, worker_threads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of the VM2 library ranging from 3.11.3 through 3.11.6 represents a critical failure in process isolation mechanisms within Node.js sandboxing environments. The core issue stems from how the crypto builtin module is exposed to the virtual machine context when explicitly permitted by configuration. Although the implementation attempts to mitigate risk by wrapping the host's native crypto module inside a recursive read-only proxy, this approach proves insufficient because it fails to restrict the execution authority of callable exports. Consequently, functions within the crypto module retain their original privileges and execute with full host-process authority rather than being confined to the restricted sandbox environment. This architectural flaw allows code running inside the VM2 sandbox to interact directly with low-level system components that should be inaccessible in a secure isolation model.
The exploitation vector centers on the ability of an attacker within the sandboxed context to invoke specific functions from the exposed crypto module, particularly setEngine(). By supplying a filesystem path pointing to a maliciously crafted native dynamic library as an argument, the attacker leverages OpenSSL's internal mechanism for loading engine plugins. When this function is called, OpenSSL delegates the task of loading the specified file to the operating system's dynamic linker. This action results in the immediate execution of arbitrary native code contained within the attacker-supplied shared object before any subsequent validation checks can reject invalid or malicious symbols. The constructor functions and initialization routines within the native library execute with the same privileges as the host Node.js process, effectively bypassing all sandbox restrictions.
This vulnerability is particularly severe because it does not require access to other dangerous built-in modules such as fs for file system operations, process for environment manipulation, module or child_process for further code execution, worker_threads for parallel processing abuse, or inspector for debugging interface exploitation. The sole requirement for successful exploitation is that the crypto builtin must be enabled in the VM2 configuration. This significantly lowers the barrier to entry for attackers and increases the likelihood of compromise in environments where cryptographic operations are necessary but strict isolation was assumed. The result is a complete sandbox escape leading to arbitrary native code execution on the host system, which can facilitate data exfiltration, lateral movement, or persistent backdoor installation depending on the context in which VM2 is deployed.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and CWE-78 Improper Neutralization of Special Elements used in an OS Command, as it involves injecting native code into a host process via dynamic loading mechanisms. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques involving Dynamic Linker/Loader Hijacking or Arbitrary Code Execution through trusted system libraries, specifically mapping to tactics related to Privilege Escalation and Defense Evasion by bypassing application sandbox controls. The failure lies in the assumption that proxying an object prevents its methods from executing with elevated privileges, a common misconception when dealing with native modules in JavaScript environments where garbage collection and memory management are handled differently than in managed languages.
Mitigation strategies must prioritize immediate upgrading to VM2 version 3.11.7 or later, which addresses this specific flaw by properly restricting the execution context of crypto module exports. For organizations unable to upgrade immediately due to dependency constraints, it is imperative to ensure that the crypto builtin is disabled within VM2 configurations unless absolutely necessary for application functionality. If cryptographic operations are required inside a sandboxed environment, developers should consider implementing these functions in an external service or worker process with its own isolated permissions and security boundaries, rather than exposing native host modules directly to untrusted code. Additionally, runtime monitoring solutions that detect unusual dynamic library loading patterns from Node.js processes can provide an additional layer of defense against exploitation attempts targeting this class of vulnerabilities.