vm2 Sandbox Escape: Incomplete AggregateError Fix Allows Host RCE (GHSA-x965-fc75-jpqh)

What happened

A new GitHub Security Advisory (GHSA-x965-fc75-jpqh, CVE-2026-92934, CVSS 9.0) reports a sandbox escape in vm2 versions up to and including 3.11.6, with a public proof-of-concept. The researcher found that the Error-sanitization fix shipped under an earlier advisory (GHSA-m283-3h24-438v) is incomplete: it correctly seals plain host-wrapped Error objects in place, but the AggregateError-specific sanitizer rebuilds a fresh wrapper instead of sealing the original. When a host-wrapped AggregateError is revisited within a single sanitization pass — via a self-cycle, a mutual cycle, or the same object referenced twice in its errors[] array — the sanitizer's cycle-detection short-circuit returns the raw, unsanitized host proxy instead of a safe replacement. According to the report, this lets sandboxed code reach that live proxy from a caught exception and call out to child_process.execSync, achieving full host command execution and disclosure of process.env. The advisory notes a related SuppressedError variant was tested and does not reproduce.

Why it matters

vm2 is widely used to sandbox untrusted JavaScript (plugin systems, serverless/multi-tenant code execution, CI tooling, bots). A sandbox escape to host RCE defeats the entire security boundary the library is meant to provide. Because the bypass specifically targets a fix that was already shipped for a prior advisory, any environment that patched GHSA-m283-3h24-438v and assumed Error-channel exfiltration was closed should treat that assumption as no longer valid for the AggregateError case.

What defenders should watch for now

• Inventory where vm2 is used to execute untrusted code, and whether any exposed host functions can throw exceptions back into sandboxed code — this is the entry point the report describes.
• Treat vm2 itself as a high-risk dependency for untrusted-code execution use cases; per the report, this is an upstream fork and the maintainers' project vm2 has previously been noted as unmaintained/deprecated in favor of alternatives (e.g., isolated-vm or OS-level sandboxing) — re-evaluate reliance on it for security boundaries.
• Hunt for anomalous child-process spawns (e.g., execSync/exec/spawn) originating from Node.js processes that host sandboxed/plugin code, especially shortly after an exception is thrown/caught in that code path.
• Review application code for patterns where host-side exceptions (particularly AggregateError instances with cyclic or duplicated nested errors) are passed into or caught by sandboxed JavaScript.
• Until a fix is confirmed, consider additional isolation (containers, seccomp, separate low-privilege processes) around any vm2-based execution rather than relying on the library's own sandboxing alone.

Developing situation

This item was published within the last day and is net-new intel — there is no confirmed CVE-mapped detection rule for it yet on this platform, and no official patched version is noted in the advisory as reviewed here. Treat details as preliminary and consult the original advisory for the authoritative technical writeup, proof-of-concept, and any vendor response: GHSA-x965-fc75-jpqh.