vm2 NodeVM Sandbox Escape: 'node:'-Prefixed Deny Rules Silently Fail to Block child_process

What happened

A new GitHub Security Advisory (GHSA-8686-vhfx-7r3j, tracked as CVE-2026-92957, CVSS 9.9) reports a sandbox-escape flaw in vm2's NodeVM. According to the advisory, when an embedder configures a builtin policy using the node:-prefixed spelling to deny a module — for example builtin: ['*', '-node:child_process'] — the deny rule silently fails to apply. The root cause described is a mismatch between how lib/setup-node-sandbox.js strips the node: prefix when resolving builtins and how lib/builtin.js checks negative entries by exact string match against canonical module names. As a result, sandboxed code can still require('child_process') or require('node:child_process') and obtain a fully functional module exposing execSync and spawn. The advisory notes its proof-of-concept only confirms module/function reachability and does not execute an OS command, but a public PoC reportedly exists.

Why it matters

Any application using vm2's NodeVM to execute untrusted or semi-trusted JavaScript — plugin systems, code-execution-as-a-service, CI/build sandboxes, bots, or developer tooling — and relying on a node:-prefixed deny entry to block child_process is affected. If the sandbox policy denies only the canonical name (e.g. -child_process), the advisory indicates that path is not affected. But any config using the node: spelling for a security-critical deny effectively has no deny in place for that module, which the advisory treats as equivalent to command-execution capability for untrusted code.

What defenders should do now

• Inventory any service embedding vm2 and check whether NodeVM builtin policies use node:-prefixed negative entries (e.g. -node:child_process, -node:fs) anywhere in the config.
• As an immediate mitigation, deny builtins using both the canonical and node:-prefixed spellings until a patched release is confirmed, and audit for any other dangerous builtins (e.g. fsfs/promises) denied only via the prefixed form.
• Treat any system running vm2 NodeVM sandboxes for untrusted code as a priority for immediate review, since vm2 has a documented history of sandbox-escape issues and this platform's policy enforcement itself is in question.
• Hunt for anomalous child-process spawning originating from Node.js processes known to host vm2 sandboxes (e.g. unexpected shell/process children from a plugin-runner or code-execution service), and review logs for use of require('node:child_process') or similar in sandboxed code paths if such logging exists.
• Track upstream for a patched vm2 release or maintainer guidance; note vm2 has had prior unresolved sandbox-escape reports, so evaluate whether migrating off vm2 to an actively maintained isolation mechanism (e.g. a separate process/container boundary) is warranted regardless of a fix timeline.

Developing situation

This is a same-day advisory and the details above reflect only what has been disclosed so far; patch availability and upstream response are not yet confirmed. We will update coverage as more information becomes available. Full technical details, root-cause analysis, and the safe reproduction steps are in the original advisory: GHSA-8686-vhfx-7r3j.