A vulnerability in the ExternalCopy component of the isolated-vm library for Node.js allows JavaScript code running in a sandbox to corrupt the host process memory and hijack its control flow. The flaw, tracked as GHSA-864f-rcv7-6rh4 with no CVE assigned yet, was disclosed on August 20, 2026, and fixed in versions 6.2.0 and 7.0.1. The bug undermines the architectural assumption underpinning agentic AI and automation platforms such as n8n, Mastra, and Sim.ai: that code generated by models or users remains confined within the V8 Isolate boundary.
- The vulnerability is a type confusion in the
isolated-vmC++ glue code, not in the V8 Isolate isolation mechanism itself, which remains intact. - The attack exploits a time-of-check/time-of-use (TOCTOU) condition in the
transferList: a stateful getter returns different values between validation and the actual data transfer across the sandbox boundary. - A single
ivm.Referenceis sufficient to escalate from a controlled crash (DoS) to control-flow hijack with potential RCE on the host system. - The library logs roughly 1 million weekly downloads on npm; projects with tens of thousands of GitHub stars — including n8n, Mastra, Sim.ai, and Activepieces — depend on it for safe execution of untrusted code.
The TOCTOU Mechanism in transferList: Validate Twice, Trust Never
The ExternalCopy component of isolated-vm handles data serialization across the boundary between the host and the V8 Isolate — the isolation unit Chrome uses to separate browser tabs. When guest JavaScript requests transfer of an array of objects across this boundary, ExternalCopy iterates over the transferList twice: first to validate the contents, then to perform the actual transfer. The array is not re-validated between the two passes.
This temporal window is the crux of the vulnerability. An attacker can define a stateful getter on the length property or on the transferList elements so that it returns a valid ArrayBuffer during the first iteration and a completely different, attacker-controlled object during the second. The mismatch triggers type confusion in the host process memory: the C++ code operates on data structures it believes are of a known type, while it has actually received others. This results in the memory corruption that enables control-flow hijack.
From a Single ivm.Reference to Host Process Control
Cristian-Alexandru Staicu of Endor Labs, the researcher who discovered and reported the vulnerability, demonstrated that the minimal entry point for the attack is extremely small. No broad or privileged sandbox access is required: a single ivm.Reference — the standard mechanism by which a host grants any capability to a guest — is enough to trigger the chain.
"Starting from nothing but a single ivm.Reference, the standard way hosts hand a sandbox any capability at all, we escalated the bug from a controlled-address crash all the way to hijacking the host's control flow, demonstrating a full guest-to-host sandbox escape." — Cristian-Alexandru Staicu, Endor Labs
The project maintainer, Marcel Laverdet, quantified the demonstrated impact spectrum: the minimum is a reliable controlled-address crash, equivalent to a denial-of-service; the maximum is hijacking the host process control flow — i.e., potential remote code execution on the underlying system. The distance between these two extremes, in the context of a sandbox designed to contain untrusted code, marks the collapse of the library's fundamental security contract.
V8 Isolate Architecture Holds, Binding Layer Fails
A critical aspect of the research is the precise localization of the failure. The V8 Isolate — Google's JavaScript engine isolation primitive — is not compromised. The isolation boundary between processes held. What collapsed is the C++ "glue" code that marshals and unmarshals values crossing that boundary — the so-called binding layer.
Staicu emphasized this distinction: "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." The case fits a pattern his research is systematically mapping: "That gap between 'the primitive is sound' and 'the system is safe' is where modern sandbox escapes increasingly live." The formulation captures a structural problem in modern software, where formally correct components are wrapped in integration layers that void their guarantees.
Agentic AI Ecosystem in the Crosshairs: When Generated Code Becomes the New Normal
The vulnerability takes on strategic relevance due to the massive adoption of isolated-vm in platforms where execution of code generated by language models or configured by users has become standard operations. According to DevOps.com, projects with significant open-source visibility depend on this library: n8n (over 200,000 GitHub stars), Mastra (27,000 stars), Sim.ai (29,000 stars), and Activepieces (23,000 stars). Other users include Screeps, Fly.io, Algolia, and TripAdvisor.
These platforms use isolated-vm precisely to run untrusted JavaScript in controlled environments — workflow automation, AI agents, user scripts. The agentic paradigm, in which models generate and execute code autonomously, exponentially amplifies the attack surface: every execution instance becomes a potential vector, and the containment guarantee becomes critical for the security of the entire system. Staicu's discovery demonstrates that this guarantee, in the case of the C++ binding layer, was illusory.
With roughly 1 million weekly downloads on npm and an active community (2,900 GitHub stars, 190 forks), isolated-vm is not a niche library. It is infrastructure. Its compromise translates into widespread exposure, often invisible to end developers who take sandboxing for granted.
What to Do Now
- Update immediately to
isolated-vmversion 6.2.0 or 7.0.1, the only releases that fix the vulnerability; all versions up to and including 7.0.0 are affected. - Verify whether your systems expose
ivm.Referenceto potentially malicious sandboxes, since even a single reference of this type is sufficient to trigger the exploit. - Audit transitive dependencies:
isolated-vmcan be pulled in indirectly via automation frameworks or AI platforms, not only as a declared direct dependency. - Monitor CVE assignment for
GHSA-864f-rcv7-6rh4and integrate the reference into vulnerability management systems as soon as it becomes available.
The Binding Layer Blind Spot and the Future of Sandboxing
The isolated-vm story is not an isolated anomaly. It is a specimen of a vulnerability class that thrives in the boundary zone between sound primitives and complex systems: the binding layer that translates abstractions, the serialization code that crosses architectural boundaries, the "glue" written in memory-unsafe languages that wraps formally verified engines. Staicu summed it up as "A perfectly sound building block was undermined by the binding layer wrapped around it."
For the AI industry, where automatic execution of generated code is rapidly expanding, the lesson is twofold: choosing robust isolation primitives is not enough; one must systematically verify the integration layer that makes them usable. The V8 Isolate works. The C++ that makes it accessible from Node.js, in this case, does not. And the difference between the two is the difference between a sandbox that contains and one that merely pretends to.
Sources
- https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
- https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
- https://thomasharris6.wordpress.com/2026/08/20/isolated-vm-flaw-lets-sandboxed-javascript-escape-to-host-for-potential-rce/
- https://devops.com/critical-flaw-in-isolated-vm-can-lead-to-sandbox-escape-rce-threat/
- https://www.csoonline.com/article/4212151/critical-flaw-patched-in-popular-javascript-sandbox-used-in-ai-projects.html
- https://podcast.securityweek.com/
Information verified against cited sources and current as of publication.