CVE-2026-100721: vm2 before 3.12.2 Authorization Bypass via Custom Resolver
vm2 before 3.12.2 contains an authorization bypass in the NodeVM external-module resolver. When an embedder configures require.external with a custom resolver (and context: 'host'), LegacyResolver.customResolve in lib/resolver-compat.js records the resolved module directory in this.externals as new RegExp('^' + escapeRegExp(resolvedPath)), without requiring a path separator or end-of-string boundary. Untrusted guest code can therefore require the allowlisted module (e.g. foo) and then require the absolute path of a non-allowlisted sibling whose path merely shares the resolved prefix (e.g. .../nodemodules/foo2/index.js); the sibling passes isPathAllowedForModule and is loaded through hostRequire, so its top-level code runs in the host process before the exports are wrapped with vm.readonly, resulting in a sandbox escape and arbitrary code execution in the host context.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.12.2
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Only NodeVM deployments that configure require.external with a custom resolver and use context: 'host' are described as affected. The bypass depends on the resolver recording an allowlisted module's resolved directory as a prefix match.
What does an attacker need to exploit the bypass?
An attacker needs the ability to run untrusted guest code in the affected NodeVM. That code must be able to require an allowlisted module and then require an absolute path to a non-allowlisted sibling module whose path shares the allowlisted module's resolved prefix.
What is the practical impact if exploitation succeeds?
The non-allowlisted sibling is loaded through hostRequire, causing its top-level code to execute in the host process before its exports are wrapped read-only. This results in a sandbox escape and arbitrary code execution in the host context.
How can I determine whether a custom resolver configuration is vulnerable?
Inspect the NodeVM require.external configuration for a custom resolver used with context: 'host'. A vulnerable setup permits a resolved allowlisted module path to authorize another module path that merely begins with the same string, such as foo and foo2.