Published · 2d agoSecurity3 min read
A sandbox escape with no CVE: isolated-vm patches, and a million weekly installs have to move
A type confusion in isolated-vm's ExternalCopy turns a single ivm.Reference into host control-flow hijack. Fixes shipped in 6.2.0 and 7.0.1, under a GHSA number and no CVE.
Not a builder's beat, but builders have a standing stake in it.See today for builders

What happened
- The vulnerability is tracked as GHSA-864f-rcv7-6rh4 and has yet to be assigned a CVE identifier.
- The flaw impacts all versions of isolated-vm before and including 7.0.0, and has been patched in versions 6.2.0 and 7.0.1, released earlier this month.
- Isolated-vm is a Node.js library for running untrusted JavaScript inside a V8 Isolate, an independent instance of the V8 engine, allowing multiple sandboxed JavaScript environments to run concurrently without sharing data or interfering with each other.
- The isolated-vm npm package has seen nearly 1 million downloads over the past week.
- The isolated-vm open-source project has more than 2,900 stars and 190 forks on GitHub.
Compiled by The WatchSomething wrong?How this is made
Why it matters
Endor Labs has disclosed a type confusion in isolated-vm's ExternalCopy class that lets code inside the sandbox corrupt memory in the host Node.js process, and the researcher credited with the find says he escalated it from a controlled crash to hijacking the host's control flow [7][8][9]. It is tracked as GHSA-864f-rcv7-6rh4 and has not been assigned a CVE identifier, which means anyone whose dependency triage starts at a CVE feed will not see it [1].
The affected range is every version before and including 7.0.0, with fixes in 6.2.0 and 7.0.1, released earlier this month according to the advisory [2]. Two consequences worth spelling out. A deployment pinned at 7.0.0, the newest release before the fix, is vulnerable [17]. And 6.2.0 sorts below 7.0.0 while being a fixed release, so the fix was backported to the 6.x line and a naive "less than 7.0.1 is bad" comparison will flag patched hosts and, worse, breed the habit of ignoring the check [16].
This matters because of where isolated-vm sits. It is the Node.js library for running untrusted JavaScript inside a V8 Isolate, letting multiple sandboxed environments run concurrently without sharing data [3]. The npm package recorded nearly a million downloads in the past week, and the GitHub project has more than 2,900 stars and 190 forks [4][5]. That is the plumbing under AI code execution, plugin runtimes, and multi-tenant eval endpoints, which is to say under a lot of products whose entire threat model is "the guest cannot reach the host."
The mechanism is unglamorous and instructive. Each isolate keeps its own heap and state, so objects cannot be handed directly from the main thread into a guest, and ExternalCopy exists to serialize values out of the host isolate and deserialize them into the guest [6]. The bug is in ExternalCopy's handling of the transferList option [8]. Endor Labs researcher Cristian-Alexandru Staicu says the starting point was nothing more than a single ivm.Reference, which he describes as the standard way hosts hand a sandbox any capability at all [9]. Maintainer Marcel Laverdet's advisory puts the floor at a reliable, controlled-address crash usable for denial of service by any guest that has been given an ivm.Reference, and the ceiling at control-flow hijack of the host process, meaning potential remote code execution [10][11]. In between sit host segfaults and a collapsed trust boundary [12]. Full exploit details have been withheld [13].
Staicu's own reading is the part to keep: the isolation primitive did not fail, V8's Isolate boundary held, and what broke was the C++ glue code marshalling values across it [14]. Sound building blocks do not confer soundness on the bindings wrapped around them.
What to watch. Whether a CVE is eventually issued and backfilled, because until it is, scanner coverage will be uneven and GHSA-only advisories travel badly through procurement and SBOM tooling [1]. Whether transitive dependents republish, since most teams do not install isolated-vm directly. And whether details of the withheld exploit surface once the patch has been public long enough to be diffed [13]. Guidance from the project is simply to update [15]; the operational work is proving that every isolate host you run actually did.
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The vulnerability is tracked as GHSA-864f-rcv7-6rh4 and has yet to be assigned a CVE identifier.
ReportedView cited source - [2]
The flaw impacts all versions of isolated-vm before and including 7.0.0, and has been patched in versions 6.2.0 and 7.0.1, released earlier this month.
ReportedView cited source - [3]
Isolated-vm is a Node.js library for running untrusted JavaScript inside a V8 Isolate, an independent instance of the V8 engine, allowing multiple sandboxed JavaScript environments to run concurrently without sharing data or interfering with each other.
ReportedView cited source - [4]
The isolated-vm npm package has seen nearly 1 million downloads over the past week.
ReportedView cited source - [5]
The isolated-vm open-source project has more than 2,900 stars and 190 forks on GitHub.
ReportedView cited source - [6]
Because each V8 Isolate has separate state and its own heap, JavaScript objects cannot be passed directly from the main Node.js thread into a worker isolate; isolated-vm exposes a class called ExternalCopy to serialize JavaScript objects out of the host isolate and deserialize them into the guest isolate.
ReportedView cited source
Sources & coverage · 1 publisher
The reporting this story was synthesized from, earliest first. Every link goes to the original.
Additional citations
- Cristian-Alexandru Staicu, Endor Labs, in a technical write-up shared with The Hacker News
- Cristian-Alexandru Staicu, Endor Labs
- Marcel Laverdet, isolated-vm maintainer, in an advisory



