vm2 Sandbox Escape Rediscovered via console._stdout Prototype Chain — No Patch Available

What Happened

A new sandbox-escape technique for vm2's NodeVM was published as GHSA-88hf-g992-jg85 on 2026-10-05, with a public CVE assignment (CVE-2026-92955) and a working proof-of-concept. According to the advisory, the underlying issue — the ability to reach the host's real __proto__ getter/setter from inside the sandbox — has already been described in at least four prior vm2 advisories (GHSA-vwrp-x96c-mhwq, GHSA-v6mx-mf47-r5wg, GHSA-grj5-jjm8-h35p, GHSA-47x8-96vw-5wg6) and was never fixed.

The new PoC exploits console._stdout/console._stderr, which are available when a NodeVM is run with the default console: 'inherit' setting. Their prototype chain leads back to Node's EventEmitter. By walking that chain with the leaked host __proto__ getter and overwriting EventEmitter.prototype.emit, the PoC gets attacker-controlled code executed with this bound to the host process object, then calls child_process.execSync to run an arbitrary shell command. The advisory notes this approach also bypasses the --disallow-code-generation-from-strings flag, which only blocks the more commonly known function-constructor escape.

Why It Matters

This is rated CVSS 10.0 with a public PoC, and it affects vm2, a widely used npm package for running untrusted JavaScript in a sandbox (e.g. plugin systems, code-execution-as-a-feature products, CI/build tooling that evaluates user-supplied scripts). Because the exploit runs arbitrary shell commands once triggered, any application that treats NodeVM as a trust boundary for third-party or user-supplied code should assume that boundary can be broken. The advisory itself emphasizes this is a recurring, unresolved class of bug in vm2 rather than a one-off defect — prior attempts to close the __proto__ leak clearly haven't held.

What Defenders Should Do Now

• Inventory where vm2 (directly or via a transitive dependency) is used to execute untrusted or third-party code, and treat it as a high-priority finding regardless of patch availability — the advisory indicates no fix currently closes this class of escape.
• Where possible, do not rely on vm2/NodeVM as a hard security boundary for untrusted code; consider process-level isolation (containers, VMs, seccomp, or dedicated sandboxing runtimes) as a compensating control.
• If NodeVM is used with console: 'inherit' (the default), consider disabling console passthrough or restricting what the sandboxed code can reach, as a partial mitigation — though the advisory suggests other escape paths via the same prototype-chain class of issue likely exist.
• From a hunting/monitoring angle, watch for Node.js processes that spawn unexpected child processes (e.g. sh, execSync-style child_process invocations) from services known to run vm2-based code evaluation, and review logging/EDR coverage for process trees originating from sandboxed-code-execution services.

Developing Intel

This item is based on a GHSA advisory published today (2026-10-05) with an associated CVE (CVE-2026-92955) and public PoC; no official patch status is confirmed in the source material at this time. Treat this as early-stage, developing intelligence and consult the original advisory for the latest details: GHSA-88hf-g992-jg85.