CVE-2026-92946

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-j3hm-6rg5-mchv. This link is maintained to preserve external references.

Original Description

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

Summary

NodeVM's require.external option lets sandboxed code require() local files and npm packages. When require.external is enabled and require.root is not explicitly set to a path that excludes node_modules, two defaults combine to fully defeat the sandbox:

• require.root defaults to unrestricted — "if omitted every path is allowed."
• require.context defaults to "host" — files loaded this way run through the real Node.js require(), not inside any vm2 sandbox.

Sandboxed code can therefore require() a relative or absolute path to vm2's own installed package (node_modules/vm2), obtain the real, unwrapped NodeVM/VM classes, construct a brand-new unrestricted nested NodeVM instance, and execute arbitrary host OS commands via child_process.

This is exploitable using vm2's own documented "Quick Examples" configuration in README.md:

const vm = new NodeVM({
  require: {
    external: true,
    root: './',
  },
});

root: './' reads as a safety restriction but, in any ordinary npm project layout, ./node_modules/vm2 sits inside that same directory tree — so the restriction does not exclude vm2 itself. An application built by following the README's quick-start guide is affected by default.

Affected Versions

All vm2 versions where lib/resolver-compat.js's makeResolverFromLegacyOptions predates this report — confirmed present as of the current main (post-3.11.5, including all fixes through GHSA-8hg8-63c5-gwmx / Category 25 and GHSA-cp6g-6699-wx9c / Category 24). Neither of those prior fixes covers this code path (see Root Cause).

Details / Root Cause

lib/resolver-compat.js:

const {
  builtin: builtinOpt,
  mock: mockOpt,
  external: externalOpt,
  root: rootPaths,
  resolve: customResolver,
  customRequire: hostRequire = defaultRequire,
  context = 'host',          // <-- defaults to 'host'
  strict = true,
  fs: fsOpt = DEFAULT_FS,
} = options;
...
if (!externalOpt) return new Resolver(fsOpt, [], builtins);
...
let checkedRootPaths;
if (rootPaths !== undefined) {
  // root is only canonicalized/validated if the embedder explicitly provided one.
  ...
}

and CustomResolver.isPathAllowed:

isPathAllowed(filename) {
  if (this.rootPaths === undefined) return true;   // <-- unrestricted when root is omitted
  ...
}

and CustomResolver.loadJS:

loadJS(vm, mod, filename) {
  if (this.pathContext(filename, 'js') !== 'host') return super.loadJS(vm, mod, filename);
  const m = this.hostRequire(filename);   // <-- real host require(), when context === 'host' (the default)
  mod.exports = vm.readonly(m);
}

CustomResolver (the resolver used whenever require.external is a bare true, i.e. not a scoped array/object) has no external-module-name allowlist at all — it gates purely on isPathAllowed, which is a no-op when root isn't set. Combined with context defaulting to 'host', any absolute or root-relative path sandboxed code names is loaded and executed via the real, unsandboxed Node.js require().

This is a distinct code path from the two already-fixed advisories that produce a similar end state:

• Category 24 / GHSA-cp6g-6699-wx9c (require.root symlink bypass) assumes root is configured and attacks the symlink boundary via a TOCTOU between path.resolve() and the native loader's symlink-following. git log -- lib/resolver-compat.js shows its fix (realpath canonicalization) is the only history that file has — nothing from the nesting fix touches it, and the fix does nothing when root is never set in the first place, since there is no boundary to attack via symlink.
• Category 25 / GHSA-8hg8-63c5-gwmx (nesting: true bypass) closes a different delivery mechanism entirely — the NESTING_OVERRIDE-injected vm2 builtin, gated by a constructor-time check on the nesting option. That check is never consulted by this path: an embedder with `nesting:…

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.