{"id":"CVE-2026-92948","aliases":["CLSA-2026-1790888247","CLSA-2026-1790937673","EUVD-2026-81597","GHSA-8686-vhfx-7r3j","GHSA-8hr7-r645-pc6w","GHSA-qhwx-74w5-xhxq","GHSA-wqg3-r97q-73xm","ROOT-APP-NPM-CVE-2026-92948"],"status":"published","title":"vm2 3.9.6 through 3.11.5 Sandbox Escape via node:test","description":"vm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","severity":{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00654,"percentile":0.51672,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-693"],"published":"2026-09-17T13:46:08Z","modified":"2026-10-28T02:30:49Z","fixes":[{"ecosystem":"npm","package":"vm2","fixed_in":["3.11.7"],"sources":["ghsa","osv"]},{"ecosystem":"Root:npm","package":"vm2","fixed_in":["3.10.5-aikido.8","3.11.6-aikido.1"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@rootio/vm2","fixed_in":["3.10.5-root.io.8","3.11.6-root.io.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.9.6"},{"last_affected":"3.11.6"},{"fixed":"3.11.7"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.11.5-tuxcare.0"},{"fixed":"3.11.5-tuxcare.3"}]}],"versions":["3.11.5","3.11.5-tuxcare.1","3.11.5-tuxcare.2"],"bundled":13},{"source":"osv","ecosystem":"TuxCare:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.10.0-tuxcare.0"},{"fixed":"3.10.0-tuxcare.2"}]}],"versions":["3.10.0","3.10.0-tuxcare.1"],"bundled":6},{"source":"osv","ecosystem":"npm","package":"vm2","ranges":[{"type":"SEMVER","events":[{"introduced":"3.9.6"},{"fixed":"3.11.7"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.10.5-aikido.8"},{"fixed":"3.11.6-aikido.1"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@rootio/vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.10.5-root.io.8"},{"fixed":"3.11.6-root.io.1"}]}]}],"products":[{"vendor":"patriksimek","product":"vm2"}],"references":[{"url":"https://github.com/patriksimek/vm2/security/advisories/GHSA-qhwx-74w5-xhxq","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/vm2-3.9.6-through-3.11.5-sandbox-escape-via-node-test","tags":["third-party-advisory","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92948","tags":["advisory"]},{"url":"https://github.com/patriksimek/vm2/commit/415339f698f0d52d3c5ad358b12b79c8072d5b4b","tags":["web"]},{"url":"https://github.com/patriksimek/vm2/releases/tag/v3.11.7","tags":["web"]},{"url":"https://github.com/advisories/GHSA-qhwx-74w5-xhxq"},{"url":"https://github.com/advisories/GHSA-wqg3-r97q-73xm"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92948.json","tags":["advisory"]},{"url":"https://github.com/patriksimek/vm2","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-92948","title":"vm2 3.9.6 through 3.11.5 Sandbox Escape via node:test","description":"vm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"published","published":"2026-09-17T13:46:08.814Z","modified":"2026-09-18T19:31:54.395Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical","assessor":"cna"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T13:48:24.536396Z"}],"euvd":[{"id":"EUVD-2026-81597","description":"vm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"published","published":"2026-09-17T13:46:08Z","modified":"2026-09-18T19:31:54Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical"}],"updated_at":"2026-11-02T17:28:07.574446Z"}],"ghsa":[{"id":"GHSA-qhwx-74w5-xhxq","title":"vm2: NodeVM builtin allowlist bypass via node:test.run() execArgv allows sandbox escape","description":"## Summary\n\nOn Node.js 24 and newer, `vm2` can expose the host `node:test` module to sandboxed `NodeVM` code when the embedder explicitly allows the `node:test` builtin. Sandbox code can reach that module through `require('node:node:test')` and call `run()` with attacker-controlled `execArgv`.\n\n`node:test.run()` starts a separate Node process for process-isolated test execution and forwards the supplied `execArgv` values to that process. Supplying `--eval=\u003cJavaScript\u003e` therefore executes arbitrary JavaScript in an unrestricted host Node process, outside the `NodeVM` sandbox.\n\nThe PoC confirms that direct sandbox imports of `fs`, `child_process`, `module`, and `process` remain denied before the spawned process imports host `fs` and writes a harmless marker.\n\n## Affected versions and environment\n\n- Package: `vm2`\n- Affected versions: `\u003e=3.9.6, \u003c=3.11.5`\n- Latest reproduced version: `3.11.5`\n- Reproduced runtime: Node.js `v24.18.0`\n- Exact path is not present on Node.js 22 because `module.builtinModules` does not expose the scheme-only `node:test` entry there\n- Configuration prerequisite:\n\n```js\nrequire: {\n  builtin: ['node:test'],\n  external: false\n}\n```\n\nThe lower version boundary was tested directly: `vm2@3.9.5` blocks `require('node:node:test')`, while `vm2@3.9.6` permits the exploit path. Representative releases through `3.11.5` were also reproduced.\n\n## Root cause\n\nThe issue is a combination of builtin admission, generic host passthrough, and prefix normalization:\n\n1. On Node.js 24+, `module.builtinModules` includes the scheme-only key `node:test`.\n2. `lib/builtin.js` builds `BUILTIN_MODULES` from that array. The family-based `DANGEROUS_BUILTINS` protection does not include `test`, so `node:test` remains eligible.\n3. When the embedder explicitly allows `node:test`, `addDefaultBuiltin()` stores it through the generic loader:\n\n```js\nbuiltins.set(key, special ? special : vm =\u003e vm.readonly(hostRequire(key)));\n```\n\n4. In `lib/setup-node-sandbox.js`, `requireImpl()` strips one `node:` prefix before builtin lookup:\n\n```js\nif (localStringPrototypeStartsWith(filename, 'node:')) {\n  id = localStringPrototypeSlice(filename, 5);\n  nmod = loadBuiltinModule(id);\n}\n```\n\n5. Consequently, sandbox code requesting `node:node:test` is normalized to the stored key `node:test` and receives a readonly proxy to the host module.\n6. The readonly proxy does not make `node:test.run()` safe. Calls are forwarded to the host implementation, which accepts attacker-controlled `execArgv` for a newly spawned Node process.\n7. `--eval=\u003cattacker JavaScript\u003e` runs outside vm2 and has normal host builtin access.\n\nThe doubled prefix is the reachability mechanism, but the security boundary failure is broader: the generic host-passthrough loader treats the `test` builtin family as safe even though its `run()` API can launch unrestricted Node processes.\n\n## Proof of concept\n\nFrom the `poc` directory:\n\n```bash\nnpm ci --ignore-scripts --no-audit --no-fund\nnode repro.js\n```\n\nExpected successful result on Node.js 24+ includes:\n\n```json\n{\n  \"vm2Version\": \"3.11.5\",\n  \"nodeVersion\": \"v24.18.0\",\n  \"markerExists\": true,\n  \"childIsDistinctProcess\": true,\n  \"marker\": {\n    \"hostCodeExecution\": true\n  }\n}\n```\n\nThe PoC writes only `host-rce-marker.json` in its own directory and does not invoke a shell, contact a network service, or access third-party data.\n\n## Impact\n\nAn attacker who is intentionally permitted to execute untrusted JavaScript in the affected `NodeVM` configuration can escape the sandbox and execute arbitrary JavaScript under the embedder's operating-system identity.\n\nThis provides the spawned process with the host user's filesystem, environment, network, and process-execution permissions. It can therefore result in complete confidentiality, integrity, and availability impact for the hosting service.\n\n## Suggested remediation\n\nTreat the normalized `test` builtin family as dangerous before wildcard expansion and explicit builtin registration.\n\nFor example, add `test` to `DANGEROUS_BUILTINS` so the existing prefix and family checks reject both `node:test` and `node:test/reporters`:\n\n```js\nconst DANGEROUS_BUILTINS = new Set([\n  // existing entries\n  'test'\n]);\n```\n\nIf test helpers must be exposed, provide a sandbox-local wrapper through `mock` or `override` that does not expose `run()`, process isolation, `execArgv`, or other host process controls.\n\nRecommended regression cases:\n\n- explicit `builtin: ['node:test']`\n- wildcard builtin configurations\n- `require('node:test')`\n- `require('node:node:test')`\n- `node:test/reporters` and prefixed variants\n- direct low-level builtin registration\n- attempts to pass `--eval`, `--require`, or `--import` through test-runner process options\n[vm2-node-test-ghsa-submission.zip](https://github.com/user-attachments/files/29930119/vm2-node-test-ghsa-submission.zip)","status":"published","published":"2026-10-01T15:41:31Z","modified":"2026-10-01T15:41:32Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T14:41:24.739884Z"},{"id":"GHSA-wqg3-r97q-73xm","title":"Duplicate Advisory: NodeVM builtin allowlist bypass via node:test.run() execArgv allows sandbox escape","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-qhwx-74w5-xhxq. This link is maintained to preserve external references.\n\n## Original Description\nvm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"withdrawn","published":"2026-09-17T15:32:15Z","modified":"2026-10-01T15:41:06Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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","level":"critical"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T14:41:24.739884Z"}],"nvd":[{"id":"CVE-2026-92948","description":"vm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"published","published":"2026-09-17T14:18:00.31Z","modified":"2026-09-18T20:17:30.98Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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","level":"critical","assessor":"secondary"},{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T14:12:49.013904Z"}],"osv":[{"id":"CVE-2026-92948","title":"vm2 3.9.6 through 3.11.5 Sandbox Escape via node:test","description":"vm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"published","published":"2026-09-17T13:46:08.814Z","modified":"2026-10-28T02:30:49.422028456Z","cvss":[{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","level":"critical"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:45:20.588039Z"},{"id":"GHSA-qhwx-74w5-xhxq","title":"vm2: NodeVM builtin allowlist bypass via node:test.run() execArgv allows sandbox escape","description":"## Summary\n\nOn Node.js 24 and newer, `vm2` can expose the host `node:test` module to sandboxed `NodeVM` code when the embedder explicitly allows the `node:test` builtin. Sandbox code can reach that module through `require('node:node:test')` and call `run()` with attacker-controlled `execArgv`.\n\n`node:test.run()` starts a separate Node process for process-isolated test execution and forwards the supplied `execArgv` values to that process. Supplying `--eval=\u003cJavaScript\u003e` therefore executes arbitrary JavaScript in an unrestricted host Node process, outside the `NodeVM` sandbox.\n\nThe PoC confirms that direct sandbox imports of `fs`, `child_process`, `module`, and `process` remain denied before the spawned process imports host `fs` and writes a harmless marker.\n\n## Affected versions and environment\n\n- Package: `vm2`\n- Affected versions: `\u003e=3.9.6, \u003c=3.11.5`\n- Latest reproduced version: `3.11.5`\n- Reproduced runtime: Node.js `v24.18.0`\n- Exact path is not present on Node.js 22 because `module.builtinModules` does not expose the scheme-only `node:test` entry there\n- Configuration prerequisite:\n\n```js\nrequire: {\n  builtin: ['node:test'],\n  external: false\n}\n```\n\nThe lower version boundary was tested directly: `vm2@3.9.5` blocks `require('node:node:test')`, while `vm2@3.9.6` permits the exploit path. Representative releases through `3.11.5` were also reproduced.\n\n## Root cause\n\nThe issue is a combination of builtin admission, generic host passthrough, and prefix normalization:\n\n1. On Node.js 24+, `module.builtinModules` includes the scheme-only key `node:test`.\n2. `lib/builtin.js` builds `BUILTIN_MODULES` from that array. The family-based `DANGEROUS_BUILTINS` protection does not include `test`, so `node:test` remains eligible.\n3. When the embedder explicitly allows `node:test`, `addDefaultBuiltin()` stores it through the generic loader:\n\n```js\nbuiltins.set(key, special ? special : vm =\u003e vm.readonly(hostRequire(key)));\n```\n\n4. In `lib/setup-node-sandbox.js`, `requireImpl()` strips one `node:` prefix before builtin lookup:\n\n```js\nif (localStringPrototypeStartsWith(filename, 'node:')) {\n  id = localStringPrototypeSlice(filename, 5);\n  nmod = loadBuiltinModule(id);\n}\n```\n\n5. Consequently, sandbox code requesting `node:node:test` is normalized to the stored key `node:test` and receives a readonly proxy to the host module.\n6. The readonly proxy does not make `node:test.run()` safe. Calls are forwarded to the host implementation, which accepts attacker-controlled `execArgv` for a newly spawned Node process.\n7. `--eval=\u003cattacker JavaScript\u003e` runs outside vm2 and has normal host builtin access.\n\nThe doubled prefix is the reachability mechanism, but the security boundary failure is broader: the generic host-passthrough loader treats the `test` builtin family as safe even though its `run()` API can launch unrestricted Node processes.\n\n## Proof of concept\n\nFrom the `poc` directory:\n\n```bash\nnpm ci --ignore-scripts --no-audit --no-fund\nnode repro.js\n```\n\nExpected successful result on Node.js 24+ includes:\n\n```json\n{\n  \"vm2Version\": \"3.11.5\",\n  \"nodeVersion\": \"v24.18.0\",\n  \"markerExists\": true,\n  \"childIsDistinctProcess\": true,\n  \"marker\": {\n    \"hostCodeExecution\": true\n  }\n}\n```\n\nThe PoC writes only `host-rce-marker.json` in its own directory and does not invoke a shell, contact a network service, or access third-party data.\n\n## Impact\n\nAn attacker who is intentionally permitted to execute untrusted JavaScript in the affected `NodeVM` configuration can escape the sandbox and execute arbitrary JavaScript under the embedder's operating-system identity.\n\nThis provides the spawned process with the host user's filesystem, environment, network, and process-execution permissions. It can therefore result in complete confidentiality, integrity, and availability impact for the hosting service.\n\n## Suggested remediation\n\nTreat the normalized `test` builtin family as dangerous before wildcard expansion and explicit builtin registration.\n\nFor example, add `test` to `DANGEROUS_BUILTINS` so the existing prefix and family checks reject both `node:test` and `node:test/reporters`:\n\n```js\nconst DANGEROUS_BUILTINS = new Set([\n  // existing entries\n  'test'\n]);\n```\n\nIf test helpers must be exposed, provide a sandbox-local wrapper through `mock` or `override` that does not expose `run()`, process isolation, `execArgv`, or other host process controls.\n\nRecommended regression cases:\n\n- explicit `builtin: ['node:test']`\n- wildcard builtin configurations\n- `require('node:test')`\n- `require('node:node:test')`\n- `node:test/reporters` and prefixed variants\n- direct low-level builtin registration\n- attempts to pass `--eval`, `--require`, or `--import` through test-runner process options\n[vm2-node-test-ghsa-submission.zip](https://github.com/user-attachments/files/29930119/vm2-node-test-ghsa-submission.zip)","status":"published","published":"2026-10-01T15:41:31Z","modified":"2026-10-01T16:00:04.787115953Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:46:54.760124Z"},{"id":"GHSA-wqg3-r97q-73xm","title":"Duplicate Advisory: NodeVM builtin allowlist bypass via node:test.run() execArgv allows sandbox escape","description":"## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-qhwx-74w5-xhxq. This link is maintained to preserve external references.\n\n## Original Description\nvm2 versions \u003e= 3.9.6 and \u003c= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval=\u003cJavaScript\u003e therefore executes arbitrary JavaScript in an unrestricted host Node process outside the NodeVM sandbox. Fixed in vm2 3.11.7.","status":"withdrawn","published":"2026-09-17T15:32:15Z","modified":"2026-10-01T16:00:04.777319536Z","cvss":[{"version":"3.1","score":9.9,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"critical"},{"version":"4.0","score":9.4,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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","level":"critical"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:46:59.131095Z"},{"id":"CLSA-2026-1790888247","title":"TuxCare security update for vm2 (15 CVEs)","description":"TuxCare rebuilt vm2 to address 15 CVEs. Fixed in 3.11.5-tuxcare.3.","status":"published","published":"2026-10-01T20:57:27Z","modified":"2026-10-15T09:47:57.771844817Z","updated_at":"2026-11-02T15:43:48.65893Z"},{"id":"CLSA-2026-1790937673","title":"TuxCare security update for vm2 (7 CVEs)","description":"TuxCare rebuilt vm2 to address 7 CVEs. Fixed in 3.10.0-tuxcare.2.","status":"published","published":"2026-10-02T10:41:13Z","modified":"2026-10-15T09:47:38.707369783Z","updated_at":"2026-11-02T15:43:49.016976Z"},{"id":"ROOT-APP-NPM-CVE-2026-92948","title":"CVE-2026-92948 in vm2 - Patched by Root","description":"Root has patched CVE-2026-92948 in the vm2 package for Root:npm. Multiple fixed versions available.","status":"published","published":"2026-10-19T07:16:29Z","modified":"2026-10-19T08:15:06.38628148Z","updated_at":"2026-11-02T15:53:27.649662Z"}]}}