Critical vm2 Sandbox Escape via crypto.setEngine() Native Library Loading (CVE-2026-92939)

What happened

A newly published GitHub Security Advisory (GHSA-46pr-c5wc-xffx, CVE-2026-92939) discloses a critical sandbox escape in vm2 3.11.6. According to the advisory, when a NodeVM sandbox allows only the crypto builtin, sandboxed code can call crypto.setEngine(enginePath) to make OpenSSL dynamically load an attacker-supplied native library path. The library's constructor executes as part of the OS loader's load process, before OpenSSL finishes validating whether the file is a usable engine — so native code runs even when vm2 ultimately raises ERR_CRYPTO_ENGINE_UNKNOWN. The advisory states the exploit needs only the crypto builtin and no other sensitive modules (no fs, child_process, process, etc.), and includes a harmless local PoC that proves native-code execution via a marker file. CVSS is listed at 9.9 with public PoC availability.

Why it matters

This is reported as a full sandbox escape to native code execution with the host Node.js process's OS-level privileges — not merely a logic bypass inside the JS sandbox. The advisory calls out the realistic blast radius as any plugin system, automation/notebook runner, or multi-tenant code execution service that stores untrusted package contents on disk and runs their JS in NodeVM while allowing crypto for routine hashing or signature verification. Per the advisory, an attacker only needs to ship a native library file inside an otherwise-inert plugin package — no file-write or process-exec builtin needs to be exposed to the sandbox. Impact described includes secrets/credential theft, persistence, lateral access via the host's network identity, cross-tenant data exposure, and host process disruption.

What defenders should watch for now

• Inventory any service embedding vm2/NodeVM for untrusted code execution (plugin marketplaces, CI/notebook runners, multi-tenant SaaS sandboxes) and check whether crypto is in the allowed builtins list.
• As an immediate mitigation per the advisory's implication, remove or restrict the crypto builtin from sandbox configurations until a patched vm2 release is available, and audit for alternative hashing libraries that don't require host crypto bridging.
• Hunt for anomalous dynamic-library loads or unexpected child processes/file writes originating from Node.js processes that host sandboxed/plugin execution, particularly around setEngine-style calls or OpenSSL engine-loading activity.
• Review any untrusted-package ingestion pipeline (plugin install, npm package extraction) for bundled native library files (.so/.dylib/.dll) as a pre-execution signal, since the advisory notes the malicious payload can be staged on disk well before the sandboxed JS runs.
• Treat vm2 generally with caution — this is one in a pattern of vm2 sandbox-escape disclosures, and the project's maintenance status should factor into any decision to keep relying on it for untrusted code execution.

Developing intel

This item was published same-day and is based solely on the linked GitHub Security Advisory; no vendor patch status, exploitation-in-the-wild reports, or downstream-affected-product list beyond vm2 itself is confirmed yet. Treat details as preliminary and consult the original advisory for updates: GHSA-46pr-c5wc-xffx.