"A type confusion in ExternalCopy's handling of the transferList option lets code running inside the sandbox corrupt memory in the host process," Endor Labs researcher Cristian-Alexandru Staicu said.
ExternalCopy, transferList, and the ivm.Reference
isolated-vm is a Node.js library that runs untrusted JavaScript inside a V8 Isolate — an independent instance of the Google V8 engine. Because each V8 Isolate keeps a separate state and heap, isolated-vm exposes a class called ExternalCopy to serialize objects out of the host isolate and deserialize them into a guest isolate. Endor Labs identified a type confusion in ExternalCopy’s handling of the transferList option that can be triggered from inside a guest sandbox.
From a single ivm.Reference to host-memory corruption
The researchers reported they began with “nothing but a single ivm.Reference, the standard way hosts hand a sandbox any capability at all,” and escalated the bug from a controlled-address crash to a full guest-to-host sandbox escape. Project maintainer Marcel Laverdet summarized the demonstrated impact: “Minimum demonstrated impact is a reliable, controlled-address crash (denial-of-service) triggerable by any guest that has been given an ivm.Reference (the standard way to grant a sandbox any capability).”
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildImpact: segmentation faults, sandbox escape, and potential remote code execution
Successful exploitation can corrupt memory in the host process and cause a segmentation fault (SIGSEGV). The researchers stopped short of publishing a full exploit; Endor Labs and the project authors describe a range of impact from denial-of-service to full control-flow hijack. As Laverdet put it, “Maximum demonstrated impact is control-flow hijack of the host process, i.e., potential remote code execution in the host.” The published write-up notes that additional exploit details have been withheld to limit the risk of enabling attacks.
Affected versions and the available patches
The flaw, tracked as GHSA-864f-rcv7-6rh4 and not yet assigned a CVE identifier in the material provided, affects all versions of isolated-vm before and including 7.0.0. The maintainers released fixes in versions 6.2.0 and 7.0.1 earlier this month. The npm package has been heavily downloaded recently — nearly 1 million downloads over the past week — and the GitHub repository has more than 2,900 stars and 190 forks, underscoring the library’s broad use.
What this means for developers, open-source maintainers, and enterprise deployers
- Developers and security teams: If you have isolated-vm installed in development or production stacks, the advisory explicitly advises updating to the patched releases (6.2.0 or 7.0.1) for optimal protection. The vulnerability can be triggered by any guest granted an ivm.Reference, so review any code paths that expose references into sandboxes.
- Open-source maintainers: The incident highlights the risk that binding or glue code — in this case, the C++ layer that marshals values across the V8 boundary — can undermine otherwise sound primitives. Maintain rigorous review and testing of binding layers that bridge language runtimes and memory domains.
- Enterprise deployers and procurement: Products or services that embed isolated-vm, or that rely on third-party systems that do, should inventory where the library is present and prioritize updates to the patched versions. The advisory note that exploit details were withheld suggests defenders must rely on patches and vendor guidance rather than public mitigations.
Why the V8 isolation boundary held, and where the failure occurred
Staicu emphasized a narrow technical point with broad implications: “The most important takeaway is that what was not broken was the isolation primitive itself. V8's Isolate boundary held. What failed was the C++ glue code that marshals values across that boundary. A perfectly sound building block was undermined by the binding layer wrapped around it.” In short, the underlying V8 isolation behaved as intended; the vulnerability arose in the code that translates and transfers data between host and guest.
The disclosure ties together three concrete facts: a type confusion in ExternalCopy's transfer handling, the use of ivm.Reference as the standard capability- granting mechanism, and the published demonstrations showing crashes and, at maximum observed impact, host control-flow hijack. The maintainers have released patched versions and the researchers withheld exploit specifics to reduce the risk of active abuse.
Users and teams that rely on isolated-vm should update to the patched releases and review any interfaces that grant ivm.Reference values to guest sandboxes. The record here is precise: the vulnerability identifier is GHSA-864f-rcv7-6rh4; patched releases are 6.2.0 and 7.0.1; and the technical root cause is a type confusion in ExternalCopy's transferList handling that can be triggered by a guest with an ivm.Reference.
Read the original advisory and technical write-up here: https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
