vm2 NodeVM: Default `require.external` Config (Including README's Own Example) Grants Full Host RCE

What happened

A newly published GitHub Security Advisory (GHSA-j3hm-6rg5-mchv, CVE-2026-92946, CVSS 10.0) reports that vm2's NodeVM sandbox can be fully bypassed when the require.external option is enabled without an explicit require.root that excludes node_modules. According to the report, two defaults combine badly: require.root is unrestricted when omitted, and require.context defaults to "host", meaning files loaded this way run through Node's real, unsandboxed require(). The advisory states that sandboxed code can use this to require() vm2's own installed package, obtain the real NodeVM class, and spin up a fresh unrestricted nested sandbox with full child_process access — yielding arbitrary command execution on the host.

Notably, the advisory claims this is reachable via the exact configuration shown in vm2's own README "Quick Examples" (require: { external: true, root: './' }), and that it is a distinct code path from two previously patched advisories (the nesting bypass and the require.root symlink bypass), so fixes for those do not cover it. A public PoC is included in the report.

Why it matters

vm2 is a widely used Node.js sandboxing library for running untrusted or third-party code (plugins, user scripts, etc.). If the reported root cause is accurate, any application that enabled require.external and either omitted require.root or set it to a path that still contains node_modules — including, per the advisory, anyone who copied the documented quick-start example — would have no meaningful sandbox boundary against code it was explicitly designed to isolate. The impact described is full RCE plus arbitrary filesystem access, and it reportedly persists even for embedders who already patched the two prior vm2 sandbox-escape advisories.

What defenders should do now

• Inventory where vm2's NodeVM is used to execute untrusted code, and check whether require.external is enabled.
• If enabled, verify whether require.root is set, and if so, whether it excludes the application's node_modules directory — per the advisory, a root like './' is not sufficient.
• Treat any vm2-sandboxed execution of untrusted code as high-risk pending a vendor patch; consider disabling require.external entirely, or isolating untrusted execution in a separate OS-level sandbox (container, VM, restricted user) rather than relying on vm2 alone.
• For hunting: watch for unexpected child-process spawns, unusual file access, or outbound network activity originating from processes that host vm2-based plugin/script execution, especially where the parent process pattern doesn't normally spawn shells.
• Note that vm2 has had multiple sandbox-escape findings historically; this report should reinforce not treating it as a hard security boundary for fully untrusted code regardless of configuration.

Developing intel

This is based on a single, recently published GHSA report and its accompanying proof of concept; it has not been independently verified here, and no vendor-confirmed fix or patched version is referenced in the source material. Treat details as provisional until confirmed by the maintainers or further analysis. Original source: GHSA-j3hm-6rg5-mchv.