CVE-2026-92939: Critical Sandbox Escape via Host Crypto setEngine Native Code Execution in vm2

CVE-2026-92939 is a critical sandbox escape vulnerability in the vm2 npm library affecting versions 3.11.3 through 3.11.6. The flaw manifests when the host Node.js crypto builtin module is permitted within a NodeVM sandbox configuration.

While vm2 wraps exposed host modules in a read-only proxy via its internal vm.readonly() function, this protection is insufficient for callable functions. The read-only wrapper prevents property modification but does not restrict or sanitize the invocation of host-process functions.

By calling crypto.setEngine(), sandboxed code can force the host Node.js process to load a dynamic library from disk. If an attacker can write a file to a location accessible by the host, this mechanism allows arbitrary native code execution and a complete sandbox escape.

The root cause lies in the architectural limitation of the vm.readonly() proxy wrapper and Node.js's delegation of cryptographic engines to OpenSSL. The proxy prevents writing properties back to the host object but still permits invoking properties that are callable functions.

When crypto.setEngine(path) is executed, the string argument is forwarded directly to OpenSSL's internal ENGINE loading mechanism. OpenSSL then requests the host operating system to dynamically load the shared library using platform-specific APIs such as dlopen on POSIX systems or LoadLibrary on Windows.

During this loading phase, the operating system's dynamic linker executes the library's static initializers or constructors immediately. This execution occurs before OpenSSL validates the library's contents or checks for valid engine exports.

Consequently, even if OpenSSL subsequently rejects the library and throws an ERR_CRYPTO_ENGINE_UNKNOWN exception, the malicious payload has already executed with the privileges of the parent Node.js process.

Prior to the fix, vm2 exposed builtin modules directly after wrapping them with vm.readonly() without inspecting their internal methods. This allowed sandboxed code to access the unmitigated crypto.setEngine API directly from the host context.

// Vulnerable pattern in lib/builtin.js
builtins.set(key, vm => vm.readonly(hostRequire(key)));

The official patch in commit aa146a77f859325e079f3bfbfe6d8309af483daa implements a sanitization layer called BUILTIN_MEMBER_SANITIZERS. This subsystem strips or overrides dangerous callable methods before the module is exposed to the sandbox.

// Patched mitigation in lib/builtin.js
function sanitizeCryptoModule(mod) {
	const copy = Object.assign({}, mod);
	copy.setEngine = function setEngine() {
		throw new Error('crypto.setEngine is disabled in vm2 sandboxes...');
	};
	return copy;
}

This approach neutralizes the risk by ensuring that calling crypto.setEngine from within the sandbox immediately throws an error within the JS runtime, preventing any lower-level calls to the operating system's loader.

Exploitation of this vulnerability requires two conditions: the sandbox must allow the crypto builtin module, and the attacker must have a method to place a compiled native library on the host filesystem.

The attack path begins with compiling a shared library containing a constructor function. For systems using GCC or Clang, this constructor is defined using __attribute__((constructor)), which triggers code execution during the initialization phase of a library load.

Once the library path is supplied to crypto.setEngine(), the OS dynamic loader maps the library into the host process memory and runs the constructor. The host process eventually catches an unknown engine exception, but by that time, the native payload has already executed.

The impact of CVE-2026-92939 is rated critical with a CVSS v3.1 score of 9.9. Because the execution transitions from the Node.js V8 sandbox into native binary execution, all sandbox restrictions are bypassed completely.

An attacker achieves arbitrary remote code execution (RCE) with the security context and system privileges of the parent Node.js process. This allows unauthorized reading of sensitive environment variables, filesystem manipulation, and establishing outbound network connections.

In environments where untrusted code execution is a core feature, such as serverless function hosting or plugin-based architectures, this flaw completely undermines the multi-tenant isolation boundary.

To address this vulnerability, administrators and developers must upgrade vm2 to version 3.11.7 or later. The patch effectively disables the vulnerable function by replacing it with a stub that throws an exception.

However, because vm2 is now deprecated and has historically had numerous structural sandbox escapes, users should transition to stronger isolation mechanisms. Secure alternatives include running untrusted code in short-lived containers, microVMs, or WebAssembly runtimes.

If upgrading is not immediately possible, configurations must be audited to ensure that the crypto module is not included in the allowed list of builtins for any NodeVM instances.