vm2 CVE-2026-100721

Requires the embedder to have configured NodeVM with require.external using a CUSTOM resolver AND context:'host' - this is a non-default deployment mode, which is why the vendor sets AT:P (attack requirement present). There must also be at least one allowlisted external module and a filesystem-adjacent, non-allowlisted sibling package whose resolved path shares the allowlisted module's prefix (e.g. node_modules/foo allowlisted, node_modules/foo2 present; scoped @scope/pkg vs @scope/pkg-evil equally affected). Given those conditions, exploitation needs no authentication or user interaction - the attacker simply supplies untrusted guest code to the sandbox (PR:N/UI:N). Deployments not using the external-module host-passthrough resolver, or without a prefix-sharing sibling package installed, are not exploitable via this vector.

This is a genuine sandbox-escape-to-RCE in vm2, the class of bug vm2 exists to prevent, so on technical severity it is top-tier. The vendor CVSS 4.0 is 9.5 (AV:N/AC:L/AT:P/PR:N/UI:N with full VC/VI/VA:H and SC/SI/SA:H), and CWE-863 (Incorrect Authorization) matches the description: an unanchored RegExp/startsWith prefix test lets guest code load a prefix-sharing sibling package whose top-level code runs in the host before vm.readonly wrapping. However, the AT:P (Attack Requirement Present) is the pivotal signal and is well-justified: exploitation is NOT default - the embedder must have configured require.external with a custom resolver AND context:'host'. That configuration gate meaningfully narrows real-world exposure and is the main reason the raw 9.5 overstates blanket risk. On exploitation signals, no EPSS score, no CISA KEV entry, and no public POC were provided; a fix is confirmed available from the vendor and the advisory ships regression tests (test/ghsa/GHSA-7q3f-wx44-378m/) that demonstrate the technique, so weaponization is low-effort for a capable attacker even though no in-the-wild use is indicated. Note also a minor source discrepancy: the description attributes the flaw to LegacyResolver.customResolve recording externals without a path boundary, while the linked commit/CHANGELOG describes the fix to LegacyResolver.isPathAllowedForModule's raw startsWith test - these are the two composed layers (specifier-space and filename-space) of the same allowlist and are consistent, not conflicting. Bottom line: real priority for anyone running vm2 with the external-module + host-context configuration; lower urgency for the many deployments that do not use that mode. vm2 is also deprecated upstream, so migration off vm2 is the durable fix.

An application embeds vm2's NodeVM to run untrusted plugins/user code and has configured require.external with a custom resolver and context:'host', allowlisting a package such as 'foo'. Guest code first requires the allowlisted 'foo', then requires the absolute path of a non-allowlisted sibling like .../node_modules/foo2/index.js, which passes the unanchored prefix check and is loaded via hostRequire, executing the sibling's top-level code in the host process and escaping the sandbox. No public exploit was provided, but vendor regression tests demonstrate the technique.