vm2 Sandbox Escape Bypasses Prior Fix via Indirect-Call Trick (CVE-2026-47698)

A new GitHub Security Advisory (GHSA-cfcw-xp6x-25gj, CVE-2026-47698) discloses a sandbox breakout in vm2, the popular Node.js sandboxing library. According to the advisory, the fix for an earlier bypass (GHSA-v6mx-mf47-r5wg) was incomplete: the mitigation checked for dangerous mutator calls of the form indirectcall.call(dangerousmutator, ...), but does not detect the same call wrapped in an extra layer of indirection — indirectcall.call(indirectcall, dangerousmutator, ...). A public proof-of-concept is included showing how this can be used to manipulate __proto__ getters/setters via Buffer.call chaining, trigger an exception path around WebAssembly.compileStreaming(), and ultimately reach e.constructor.constructor("return process")() to obtain a Node.js process object and execute arbitrary shell commands via child_process.execSync.

Why It Matters

This is scored 9.8 (critical) with a public PoC already available. Any application that uses vm2 to execute untrusted or semi-trusted JavaScript — code-execution playgrounds, plugin systems, serverless-style multi-tenant scripting, CI/CD sandboxes, chatbot or automation "code interpreter" features — should treat this as a full sandbox failure rather than a partial weakness. Successful exploitation yields arbitrary command execution on the host running the sandbox, not just data leakage from within the VM context. Because it bypasses a previous official fix, organizations that patched for the earlier advisory and considered the issue closed may have a false sense of safety.

What Defenders Should Do Now

• Inventory any service that depends on vm2 (directly or transitively via other npm packages) — it is worth noting the vm2 project itself has been effectively unmaintained/deprecated in favor of alternatives, so a patched release may not be forthcoming.
• Treat vm2-based isolation as untrusted for security boundaries until an upstream fix is confirmed; consider migrating to OS/process-level isolation (containers, gVisor, Firecracker) or a maintained sandboxing approach rather than relying on JS-level sandbox escapes being fully closed.
• Hunt for anomalous child-process spawns (e.g., execSync/exec/spawn calls) originating from Node.js processes that host code-execution or scripting features, especially where the parent process wasn't expected to fork shells.
• Watch for unusual WebAssembly compilation attempts or exception-handling patterns immediately followed by process/child_process object access in application logs, if such logging exists.
• Review any exposed "run code" or plugin-execution endpoints for rate limiting and network egress restrictions as defense-in-depth, since sandbox escapes convert code-execution features directly into host compromise.

This is a fresh, single-source disclosure and details may evolve — no confirmed in-the-wild exploitation has been reported at this time. For the full technical writeup and PoC, see the original GitHub Security Advisory: GHSA-cfcw-xp6x-25gj.