{"id":"CVE-2026-92962","aliases":["CLSA-2026-1787860907","EUVD-2026-81612","GHSA-2c9f-f88g-g76p","GHSA-2cm2-m3w5-gp2f","GHSA-m5w8-4gq2-6f8x","GHSA-q3fm-4wcw-g57x","GHSA-v836-6xw4-9cx3"],"status":"published","title":"vm2 before 3.11.4 Defense Invariant Violation via setup-sandbox.js","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","severity":{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00155,"percentile":0.04697,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-693"],"published":"2026-05-29T17:38:33Z","modified":"2026-10-28T02:31:06Z","fixes":[{"ecosystem":"npm","package":"vm2","fixed_in":["3.11.4"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"vm2","fixed_in":["3.10.0-tuxcare.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.11.3"},{"fixed":"3.11.4"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"vm2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.10.0-tuxcare.0"},{"fixed":"3.10.0-tuxcare.1"}]}],"versions":["3.10.0"]},{"source":"osv","ecosystem":"npm","package":"vm2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"3.11.4"}]}]}],"products":[{"vendor":"patriksimek","product":"vm2"}],"references":[{"url":"https://github.com/patriksimek/vm2/security/advisories/GHSA-q3fm-4wcw-g57x","tags":["vendor-advisory","exploit","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/vm2-before-3.11.4-defense-invariant-violation-via-setup-sandbox-js","tags":["third-party-advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-92962","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-2c9f-f88g-g76p"},{"url":"https://github.com/patriksimek/vm2/commit/ad31adc1fc4a2c163f2f8c11ab4af206074528fd","tags":["web"]},{"url":"https://github.com/patriksimek/vm2/releases/tag/v3.11.4","tags":["web"]},{"url":"https://github.com/advisories/GHSA-q3fm-4wcw-g57x"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/92xxx/CVE-2026-92962.json","tags":["advisory"]},{"url":"https://github.com/patriksimek/vm2","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-92962","title":"vm2 before 3.11.4 Defense Invariant Violation via setup-sandbox.js","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","status":"published","published":"2026-09-17T13:46:18.295Z","modified":"2026-09-17T15:40:44.491Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low","assessor":"cna"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T13:48:35.749498Z"}],"euvd":[{"id":"EUVD-2026-81612","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","status":"published","published":"2026-09-17T13:46:18Z","modified":"2026-09-17T15:40:44Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low"}],"updated_at":"2026-11-02T17:28:11.273554Z"}],"ghsa":[{"id":"GHSA-2c9f-f88g-g76p","title":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3,...","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","status":"published","published":"2026-09-17T15:32:17Z","modified":"2026-09-17T15:32:23Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/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":"low"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:12:04.687174Z"},{"id":"GHSA-q3fm-4wcw-g57x","title":"vm2 setup-sandbox.js violates Defense Invariant #11 in stack-trace formatter","description":"## Summary\n\n`defaultSandboxPrepareStackTrace` in `lib/setup-sandbox.js` (lines 605, 607) appends to a fresh sandbox-realm `lines = []` via `lines[lines.length] = value`. This is the exact invariant-violating pattern that GHSA-9qj6-qjgg-37qq (commit ca195f0, 2026-05-01) just patched in `neutralizeArraySpeciesBatch` and codified as Defense Invariant #11 (\"Bridge-internal containers must not invoke sandbox code\"). A sandbox-installed `Array.prototype[N]` setter fires during the bridge's safe-default stack-trace formatting and observes / intercepts each appended line.\n\n## Details\n\nThe post-9qj6 audit note in `docs/ATTACKS.md` (line 2111) states:\n\n\u003e Equivalent pattern elsewhere in the bridge: audited; thisFromOtherArguments, otherFromThisArguments, and every other index-write site already use thisReflectDefineProperty or otherReflectDefineProperty. neutralizeArraySpeciesBatch was the lone outlier.\n\nThe audit is scoped to `lib/bridge.js`. `lib/setup-sandbox.js` was not covered. `defaultSandboxPrepareStackTrace` (added under post-#563 hardening for GHSA-v27g) constructs a sandbox-realm `[header]` array and appends each frame via the prototype-walking index assignment:\n\n```\n// lib/setup-sandbox.js, lines 601-610\nconst lines = [header];\nfor (let i = 0; i \u003c callSites.length; i++) {\n    try {\n        lines[lines.length] = '    at ' + callSites[i];\n    } catch (e) {\n        lines[lines.length] = '    at \u003cerror formatting frame\u003e';\n    }\n}\nreturn lines.join('\\n');\n```\n\nThis function runs every time sandbox code reads `error.stack` (or any path that triggers `Error.prepareStackTrace`). At the time it runs, user code has already had the opportunity to install a setter on `Array.prototype[N]`. Because `lines` starts at length 1, the first iteration writes index 1; if `lines[1]` has no own data property, V8 walks the prototype chain and invokes the sandbox-controlled setter.\n\nThe currently-assigned value is the string `'    at ' + callSites[i]` (the wrapped `CallSite` class's safe `toString()` returns `'CallSite {}'`), which limits the immediate impact to a side channel, not an RCE pivot. The concern is structural rather than exploit-today:\n\n- The just-codified Defense Invariant #11 explicitly requires that any list, set, or map allocated for the bridge's exclusive use must read and write through identity-stable, prototype-bypassing primitives. This site does not.\n- The `catch` branch at line 607 also uses the same pattern, so a sandbox getter that throws on `callSites[i]` access still routes its retry write through the prototype chain.\n- A future change that makes the appended slot value an object holding a host-realm reference (for example, an enriched frame record) would re-introduce the exact GHSA-9qj6 attack shape against this codepath.\n\nThe fix is mechanical and mirrors the GHSA-9qj6 patch: install entries via `localReflectDefineProperty` so each appended slot is an own data property and the prototype-chain setter is bypassed.\n\n```javascript\n// Suggested patch (sketch)\nlet linesLen = 1;\nfunction append(s) {\n    localReflectDefineProperty(lines, linesLen, {\n        __proto__: null,\n        value: s,\n        writable: true,\n        enumerable: true,\n        configurable: true,\n    });\n    linesLen++;\n}\nfor (let i = 0; i \u003c callSites.length; i++) {\n    try {\n        append('    at ' + callSites[i]);\n    } catch (e) {\n        append('    at \u003cerror formatting frame\u003e');\n    }\n}\n```\n\nThe same pattern at `callSiteGetters[callSiteGetters.length] = {...}` (line 649) runs only at sandbox setup, before user code can install setters, so it is safe today. Converting it for symmetry would be cheap and forward-compatible.\n\n## PoC\n\nvm2 v3.11.2, Node v24.\n\n```javascript\nconst { VM } = require('vm2');\nconst result = new VM().run(`\n    var observed = { setterFired: false, capturedValue: null, indexFired: null };\n    Object.defineProperty(Array.prototype, 1, {\n        configurable: true,\n        set(value) {\n            observed.setterFired = true;\n            observed.indexFired = 1;\n            observed.capturedValue =\n                typeof value === 'string' ? value.slice(0, 40) : typeof value;\n        },\n        get() { return undefined; }\n    });\n    var e = new Error('x');\n    e.stack;\n    observed;\n`);\nconsole.log(result);\n// {\n//   setterFired: true,\n//   capturedValue: '    at CallSite {}',\n//   indexFired: 1\n// }\n```\n\nSandbox code observed and intercepted the bridge-internal write to `lines[1]`. Repeating the PoC with the setter installed at multiple indices (0, 1, 2, ...) captures every frame the formatter would otherwise return.\n\n## Impact\n\nHardening / Defense Invariant #11 violation. No direct sandbox escape on the current codebase: the value passed to the setter is a primitive string after the wrapped `CallSite.toString()`, so attacker-controlled code does not gain a host-realm reference from the setter argument alone. The GHSA-9qj6 entry's \"Considered Attack Surfaces\" note states the audit covered `lib/bridge.js` index-write sites; this filing reports the equivalent pattern in `lib/setup-sandbox.js` so the invariant is uniform across the bridge boundary and future enrichments of the appended record cannot regress into the GHSA-9qj6 shape.","status":"published","published":"2026-05-29T17:38:33Z","modified":"2026-05-29T17:38:34Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T14:40:14.666177Z"}],"nvd":[{"id":"CVE-2026-92962","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","status":"published","published":"2026-09-17T14:18:02.61Z","modified":"2026-09-17T16:18:34.94Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/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":"low","assessor":"secondary"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T14:12:49.013904Z"}],"osv":[{"id":"CVE-2026-92962","title":"vm2 before 3.11.4 Defense Invariant Violation via setup-sandbox.js","description":"vm2 is a sandbox for running untrusted JavaScript. In vm2 versions up to and including 3.11.3, the defaultSandboxPrepareStackTrace function in lib/setup-sandbox.js builds its output array using prototype-walking index assignment (lines[lines.length] = value) rather than a prototype-bypassing define-property primitive. Because this bridge-internal array is allocated in the sandbox realm, code inside the sandbox can install an accessor on Array.prototype for the relevant index; the accessor is then invoked whenever the sandbox reads error.stack (or otherwise triggers Error.prepareStackTrace), allowing sandbox code to observe and intercept each stack-trace line written by the bridge. The same pattern is used in the error-handling (catch) branch. The values written are formatted strings only, so the practical impact is limited to an information side channel and a violation of vm2's bridge-container defense invariant rather than a sandbox escape; the vendor rates the issue Low. The issue is fixed in vm2 3.11.4, which installs each entry as an own data property via Reflect.defineProperty.","status":"published","published":"2026-09-17T13:46:18.295Z","modified":"2026-10-28T02:31:06.527393761Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:45:20.588039Z"},{"id":"GHSA-q3fm-4wcw-g57x","title":"vm2 setup-sandbox.js violates Defense Invariant #11 in stack-trace formatter","description":"## Summary\n\n`defaultSandboxPrepareStackTrace` in `lib/setup-sandbox.js` (lines 605, 607) appends to a fresh sandbox-realm `lines = []` via `lines[lines.length] = value`. This is the exact invariant-violating pattern that GHSA-9qj6-qjgg-37qq (commit ca195f0, 2026-05-01) just patched in `neutralizeArraySpeciesBatch` and codified as Defense Invariant #11 (\"Bridge-internal containers must not invoke sandbox code\"). A sandbox-installed `Array.prototype[N]` setter fires during the bridge's safe-default stack-trace formatting and observes / intercepts each appended line.\n\n## Details\n\nThe post-9qj6 audit note in `docs/ATTACKS.md` (line 2111) states:\n\n\u003e Equivalent pattern elsewhere in the bridge: audited; thisFromOtherArguments, otherFromThisArguments, and every other index-write site already use thisReflectDefineProperty or otherReflectDefineProperty. neutralizeArraySpeciesBatch was the lone outlier.\n\nThe audit is scoped to `lib/bridge.js`. `lib/setup-sandbox.js` was not covered. `defaultSandboxPrepareStackTrace` (added under post-#563 hardening for GHSA-v27g) constructs a sandbox-realm `[header]` array and appends each frame via the prototype-walking index assignment:\n\n```\n// lib/setup-sandbox.js, lines 601-610\nconst lines = [header];\nfor (let i = 0; i \u003c callSites.length; i++) {\n    try {\n        lines[lines.length] = '    at ' + callSites[i];\n    } catch (e) {\n        lines[lines.length] = '    at \u003cerror formatting frame\u003e';\n    }\n}\nreturn lines.join('\\n');\n```\n\nThis function runs every time sandbox code reads `error.stack` (or any path that triggers `Error.prepareStackTrace`). At the time it runs, user code has already had the opportunity to install a setter on `Array.prototype[N]`. Because `lines` starts at length 1, the first iteration writes index 1; if `lines[1]` has no own data property, V8 walks the prototype chain and invokes the sandbox-controlled setter.\n\nThe currently-assigned value is the string `'    at ' + callSites[i]` (the wrapped `CallSite` class's safe `toString()` returns `'CallSite {}'`), which limits the immediate impact to a side channel, not an RCE pivot. The concern is structural rather than exploit-today:\n\n- The just-codified Defense Invariant #11 explicitly requires that any list, set, or map allocated for the bridge's exclusive use must read and write through identity-stable, prototype-bypassing primitives. This site does not.\n- The `catch` branch at line 607 also uses the same pattern, so a sandbox getter that throws on `callSites[i]` access still routes its retry write through the prototype chain.\n- A future change that makes the appended slot value an object holding a host-realm reference (for example, an enriched frame record) would re-introduce the exact GHSA-9qj6 attack shape against this codepath.\n\nThe fix is mechanical and mirrors the GHSA-9qj6 patch: install entries via `localReflectDefineProperty` so each appended slot is an own data property and the prototype-chain setter is bypassed.\n\n```javascript\n// Suggested patch (sketch)\nlet linesLen = 1;\nfunction append(s) {\n    localReflectDefineProperty(lines, linesLen, {\n        __proto__: null,\n        value: s,\n        writable: true,\n        enumerable: true,\n        configurable: true,\n    });\n    linesLen++;\n}\nfor (let i = 0; i \u003c callSites.length; i++) {\n    try {\n        append('    at ' + callSites[i]);\n    } catch (e) {\n        append('    at \u003cerror formatting frame\u003e');\n    }\n}\n```\n\nThe same pattern at `callSiteGetters[callSiteGetters.length] = {...}` (line 649) runs only at sandbox setup, before user code can install setters, so it is safe today. Converting it for symmetry would be cheap and forward-compatible.\n\n## PoC\n\nvm2 v3.11.2, Node v24.\n\n```javascript\nconst { VM } = require('vm2');\nconst result = new VM().run(`\n    var observed = { setterFired: false, capturedValue: null, indexFired: null };\n    Object.defineProperty(Array.prototype, 1, {\n        configurable: true,\n        set(value) {\n            observed.setterFired = true;\n            observed.indexFired = 1;\n            observed.capturedValue =\n                typeof value === 'string' ? value.slice(0, 40) : typeof value;\n        },\n        get() { return undefined; }\n    });\n    var e = new Error('x');\n    e.stack;\n    observed;\n`);\nconsole.log(result);\n// {\n//   setterFired: true,\n//   capturedValue: '    at CallSite {}',\n//   indexFired: 1\n// }\n```\n\nSandbox code observed and intercepted the bridge-internal write to `lines[1]`. Repeating the PoC with the setter installed at multiple indices (0, 1, 2, ...) captures every frame the formatter would otherwise return.\n\n## Impact\n\nHardening / Defense Invariant #11 violation. No direct sandbox escape on the current codebase: the value passed to the setter is a primitive string after the wrapped `CallSite.toString()`, so attacker-controlled code does not gain a host-realm reference from the setter argument alone. The GHSA-9qj6 entry's \"Considered Attack Surfaces\" note states the audit covered `lib/bridge.js` index-write sites; this filing reports the equivalent pattern in `lib/setup-sandbox.js` so the invariant is uniform across the bridge boundary and future enrichments of the appended record cannot regress into the GHSA-9qj6 shape.","status":"published","published":"2026-05-29T17:38:33Z","modified":"2026-09-18T03:56:05.252811949Z","cvss":[{"version":"4.0","score":2.1,"vector":"CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N","level":"low"}],"cwes":["CWE-693"],"updated_at":"2026-11-02T15:46:54.055966Z"},{"id":"CLSA-2026-1787860907","title":"TuxCare security update for vm2 (34 CVEs)","description":"TuxCare rebuilt vm2 to address 34 CVEs. Fixed in 3.10.0-tuxcare.1.","status":"published","published":"2026-08-27T20:01:47Z","modified":"2026-10-15T09:48:03.095721636Z","updated_at":"2026-11-02T15:43:47.591214Z"}]}}