vm2 NodeVM Custom Resolver Flaw Lets Sandboxed Guests Escape Via Prefix-Sharing Sibling Modules (CVE-2026-100721)

A new GitHub Security Advisory (GHSA-5h3f-q97h-ccvc) reports a sandbox-escape authorization bypass in vm2's NodeVM, tracked as CVE-2026-100721 with a reported CVSS of 10.0 and a public PoC.

What was reported

According to the advisory, when an embedder configures NodeVM with a custom module resolver, an external allowlist (require.external), and context: 'host', the resolver's authorization check is flawed. LegacyResolver.customResolve stores the resolved path as a raw regex prefix (^<path>) with no separator or end-of-string boundary. A guest script can therefore first require an allowlisted module (e.g. foo) and then require an absolute path to an unrelated sibling module whose name merely shares that string prefix (e.g. foo2). The sibling is not itself allowlisted, but the loose regex matches it, so it loads via hostRequire in the host context. The advisory's PoC shows the sibling invoking child_process at load time, demonstrating host-side code execution. A negative control confirms the sibling is denied (ENOTFOUND) when the allowlisted module isn't required first, isolating the custom-resolve step as the cause.

Why it matters for defenders

This affects any service that runs untrusted or third-party JavaScript inside a vm2 NodeVM sandbox using a custom resolver plus a host-context external allowlist — a pattern used by some plugin systems, CI/build tooling, and multi-tenant script-execution platforms. The reported impact is full host confidentiality, integrity, and availability compromise, not merely a sandbox exception or crash, since guest code gets a path to execute arbitrary host-side logic (including spawning processes) rather than remaining confined to the VM. The advisory is explicit that this is a narrower, residual bypass distinct from two prior public GHSAs/fixes for similar prefix-matching issues in vm2 — those earlier patches did not touch this particular code path, so patching for the older advisories alone may not be sufficient.

What defenders should watch for or do now

• Inventory any service embedding vm2's NodeVM and check whether it uses a custom resolve() function together with require.external allowlisting and context: 'host' — the advisory states this specific combination is required for exploitation.
• Treat vm2 as unmaintained/high-risk for untrusted-code execution; the advisory states no patched version was identified for this issue at the time of testing. Consider migrating untrusted-script execution to isolate-based or OS-level sandboxing (e.g. separate processes/containers with least-privilege) rather than relying on vm2's module-boundary enforcement.
• At a high level, hunting/detection angles include monitoring for unexpected child-process spawns originating from Node.js processes that host script-sandboxing functionality, and auditing application logs for require/module-load calls to paths outside the intended allowlisted directory tree.
• If a custom resolver is in use, review whether resolved paths are later checked with exact-match or separator-bounded comparisons rather than raw string-prefix regexes, per the advisory's suggested fix approach.

Developing intel

This is a same-day disclosure and the underlying detail — exact affected version range, any forthcoming patch, and broader applicability beyond the tested configuration — may evolve. The advisory itself notes only the pinned source revision was tested. Review the full technical writeup and PoC at the original source: GHSA-5h3f-q97h-ccvc.