vm2 before 3.12.1 Sandbox Escape via Promise Symbol.species
vm2 (npm) versions 3.12.0 and earlier contain a sandbox escape in `VM` and `NodeVM`. When an embedder exposes a host API that returns a host-realm Promise, the bridge's rejection sanitizer (hostPromiseSanitizeReject / makeSanitizedPromiseCallback / normalizeHostPromiseCallbacks in lib/bridge.js) only wraps `then`/`catch` rejection slots that hold a function, and the sandbox-side `Symbol.species`/`.then` neutralization is installed only on the sandbox intrinsic `Promise.prototype`, so it never applies to a host Promise. Code running inside the sandbox can overwrite `p.constructor[Symbol.species]` on the host Promise and then call `p.then()` with no `onRejected` handler; V8 substitutes its internal Thrower, which re-throws the raw host rejection value into a resolve/reject closure captured by the attacker. This delivers an unsanitized, fully functional bridge proxy of the host object to sandboxed code, bypassing handleException and hostPromiseSanitizeReject. If the rejection value is host-pivotable (for example a host `process` object), this results in arbitrary code execution on the host. Fixed in 3.12.1.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-93606
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 7 Nov 2026, 16:25 UTC · Revision 1
Source evidence
vm2 before 3.12.1 Sandbox Escape via Promise Symbol.species
core-osv · Original sourcePublished 18 Sept 2026, 13:20 UTC
vm2 (npm) versions 3.12.0 and earlier contain a sandbox escape in `VM` and `NodeVM`. When an embedder exposes a host API that returns a host-realm Promise, the bridge's rejection sanitizer (hostPromiseSanitizeReject / makeSanitizedPromiseCallback / normalizeHostPromiseCallbacks in lib/bridge.js) only wraps `then`/`catch` rejection slots that hold a function, and the sandbox-side `Symbol.species`/`.then` neutralization is installed only on the sandbox intrinsic `Promise.prototype`, so it never applies to a host Promise. Code running inside the sandbox can overwrite `p.constructor[Symbol.species]` on the host Promise and then call `p.then()` with no `onRejected` handler; V8 substitutes its internal Thrower, which re-throws the raw host rejection value into a resolve/reject closure captured by the attacker. This delivers an unsanitized, fully functional bridge proxy of the host object to sandboxed code, bypassing handleException and hostPromiseSanitizeReject. If the rejection value is host-pivotable (for example a host `process` object), this results in arbitrary code execution on the host. Fixed in 3.12.1.
osv:CVE-2026-93606
Complete source record
{
"id": "b40d0ff611bbd349e13f871d11e61859c24f81bebcdfad0f977c9c4cdcfe9265",
"url": "https://osv.dev/vulnerability/CVE-2026-93606",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "vm2 before 3.12.1 Sandbox Escape via Promise Symbol.species",
"summary": "vm2 (npm) versions 3.12.0 and earlier contain a sandbox escape in `VM` and `NodeVM`. When an embedder exposes a host API that returns a host-realm Promise, the bridge's rejection sanitizer (hostPromiseSanitizeReject / makeSanitizedPromiseCallback / normalizeHostPromiseCallbacks in lib/bridge.js) only wraps `then`/`catch` rejection slots that hold a function, and the sandbox-side `Symbol.species`/`.then` neutralization is installed only on the sandbox intrinsic `Promise.prototype`, so it never applies to a host Promise. Code running inside the sandbox can overwrite `p.constructor[Symbol.species]` on the host Promise and then call `p.then()` with no `onRejected` handler; V8 substitutes its internal Thrower, which re-throws the raw host rejection value into a resolve/reject closure captured by the attacker. This delivers an unsanitized, fully functional bridge proxy of the host object to sandboxed code, bypassing handleException and hostPromiseSanitizeReject. If the rejection value is host-pivotable (for example a host `process` object), this results in arbitrary code execution on the host. Fixed in 3.12.1.",
"evidence": "osv:CVE-2026-93606",
"products": [],
"severity": "critical",
"structured": {
"id": "CVE-2026-93606",
"aliases": [
"CVE-2026-93606",
"GHSA-6454-5x88-m6jw"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/patriksimek/vm2",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "45e32a69f09717990e83848a313b817bb758f170"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "3.12.1"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
}
]
}
}
],
"versions": [
"v3.12.0",
"v3.11.8",
"v3.11.7",
"3.11.6",
"v3.11.5",
"v3.11.4",
"v3.11.3",
"v3.11.2",
"v3.11.1",
"v3.11.0",
"v3.10.5",
"v3.10.4",
"v3.10.3",
"v3.10.2",
"v3.10.1",
"v3.10.0",
"3.9.19",
"3.9.18",
"3.9.17",
"3.9.16",
"3.9.15",
"3.9.14",
"3.9.13",
"3.9.12",
"3.9.11",
"3.9.10",
"3.9.9",
"3.9.8",
"3.9.7",
"3.9.6",
"3.9.5",
"3.9.4",
"3.9.3",
"v3.9.2",
"v3.9.1",
"v3.9.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93606.json"
}
}
],
"modified": "2026-10-28T02:30:51.383348903Z",
"provider": "osv",
"references": [
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93606.json",
"https://github.com/patriksimek/vm2/security/advisories/GHSA-6454-5x88-m6jw",
"https://nvd.nist.gov/vuln/detail/CVE-2026-93606",
"https://www.vulncheck.com/advisories/vm2-before-3.12.1-sandbox-escape-via-promise-symbol-species"
],
"provider_metadata": {
"cwe_ids": [
"CWE-693"
],
"cna_assigner": "VulnCheck",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93606.json"
}
},
"related_cves": [
{
"value": "CVE-2026-93606",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 519867,
"published_at": "2026-09-18T13:20:15.036+00:00"
}