vm2 3.11.3 through 3.11.6 expose the host Node.js crypto module to a sandboxed NodeVM when the crypto builtin is allowed. The exposed module is wrapped in a read‑only proxy, but its callable exports run with host‑process authority. A malicious script can therefore invoke crypto.setEngine() with a filesystem path to an attacker‑supplied native library. OpenSSL loads the library, executing its constructor code in the host process before performing engine‑symbol validation, which then rejects the library. The result is arbitrary native code execution in the host process, a classic remote code execution vulnerability.

The affected product is patriksimek vm2. Versions 3.11.3, 3.11.4, 3.11.5, and 3.11.6 are vulnerable. The issue has been fixed in version 3.11.7.

The CVSS score of 9.4 reflects a critical severity. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog. Exploitation requires only that the crypto builtin be present in the sandbox; no additional modules such as fs, process, module, child_process, worker_threads, vm, or inspector are needed. This means that any application exposing the crypto builtin through vm2 can be exploited to achieve host‑process code execution, making the attack vector high and the risk significant for systems that run untrusted code.