CVE-2026-92939: vm2 3.11.3 through 3.11.6 Native Code Execution via crypto.setEngine
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, childprocess, workerthreads, vm, or inspector access, resulting in a sandbox escape and arbitrary native code execution. Fixed in 3.11.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.11.7 - Compensating control
If using vm2 versions 3.11.3 through 3.11.6, ensure the crypto builtin is not allowed for the NodeVM sandbox to prevent access to the host Node.js crypto module (crypto.setEngine).
- Compensating control
For vm2 versions 3.11.3 through 3.11.6, restrict sandbox usage that would allow crypto.setEngine to be called with a filesystem path, since OpenSSL will load the attacker-supplied native library and execute native code before engine-symbol validation rejects it.
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using vm2 versions 3.11.3 through 3.11.6 are exposed when a NodeVM sandbox is configured to allow the crypto builtin. The issue applies even if other powerful builtins such as fs, process, module, child_process, worker_threads, vm, and inspector are unavailable.
What does an attacker need to exploit this?
An attacker needs the ability to run JavaScript in the affected NodeVM sandbox and to provide a filesystem path to an attacker-supplied native library already present on disk. No user interaction or additional builtin access is required beyond crypto.
Is the default sandbox configuration affected?
The provided information only identifies configurations where the crypto builtin is allowed as affected. It does not state whether crypto is allowed by default.
What should be done if the update cannot be applied immediately?
Remove or disable the crypto builtin for untrusted NodeVM sandboxes. This prevents the described crypto.setEngine() path from being available.
How can I determine whether an environment is already at risk?
Check whether vm2 is version 3.11.3 through 3.11.6 and whether any NodeVM configuration permits the crypto builtin for untrusted code. Upgrade to version 3.11.7 to obtain the fix.