vm2 NodeVM External Allowlist Bypass via Package Name Collision (CVE-2026-92951)

A newly published GitHub Security Advisory (GHSA-c48m-32m9-vx93) discloses a critical flaw in vm2, the Node.js sandboxing library used to isolate and execute untrusted JavaScript. The issue is tracked as CVE-2026-92951 and carries a CVSS score of 9.9, with a public proof-of-concept already available.

What was reported

According to the advisory, vm2's NodeVM supports a require.external allowlist to restrict which npm packages sandboxed code may load, often paired with a custom require.resolve callback. The flaw is that vm2 builds the allowlist check as a non-anchored substring match rather than an exact package-name match. A package like left-pad on the allowlist will also pass the check for a colliding name such as evil-left-pad or left-pad-backdoor. If that colliding package already exists (or is later placed) in a path reachable by the custom resolver, vm2 loads and executes it in the host context — bypassing the sandbox's module restrictions, including a builtin: [] lockdown. The researchers demonstrated this leading to host-side child_process execution in their PoC.

The advisory is explicit that this does not mean vm2 downloads malicious packages from npm on its own — exploitation requires the colliding package to already be reachable by the resolver (e.g., via a plugin-upload directory, user-controllable dependency path, or private registry sync).

Why it matters for defenders

This affects any application using vm2's NodeVM with an external allowlist and a custom resolver — a pattern common in plugin systems, user-script platforms, and multi-tenant sandboxed execution environments. Where it applies, the vulnerability defeats the core promise of the allowlist: that only explicitly trusted dependencies can run. In environments where attackers can influence what lands in a resolver-reachable path (uploads, shared dependency caches, mirrored registries), this can translate into arbitrary code execution in the host process — with access to host files, environment variables, and secrets.

What defenders should watch for or do now

• Inventory any services embedding vm2's NodeVM with both an external allowlist and a custom resolve callback — this is the specific configuration at risk.
• Audit whether any directory reachable by your custom resolver can be influenced by untrusted input (plugin uploads, user scripts, dependency sync jobs) and treat that as an active attack surface.
• Hunt for unexpected or newly-written packages in resolver-reachable directories with names that are superstrings of allowlisted package names (e.g., *left-pad* variants if left-pad is allowlisted).
• Watch for anomalous child-process spawns or unexpected module loads originating from sandbox worker processes, especially where sandboxed code should have no access to child_process or other sensitive builtins.
• Until a fix is available, consider tightening or removing custom resolvers, restricting resolver search paths to fully trusted, immutable locations, or adding your own exact-match enforcement in front of vm2's allowlist.

This is developing intel based on a same-day GHSA publication; details on patched versions were not included in the advisory as reviewed. Track the original advisory for updates: GHSA-c48m-32m9-vx93.