# Critical Type Confusion in isolated-vm (GHSA-864f-rcv7-6rh4) Enables Sandbox Escape and RCE on Host

> A time-of-check/time-of-use (TOCTOU) type confusion in isolated-vm's ExternalCopy handling of the transferList option lets JavaScript running inside a guest V8 isolate corrupt host process memory, escalating from a controlled crash to a demonstrated control-flow hijack of the host. isolated-vm is downloaded nearly 1M times/week and underpins the code-execution sandbox in multiple AI-agent and low-code automation platforms; fixes shipped in 6.2.0 and 7.0.1.

- **Published:** 2026-08-23T00:00:00Z
- **Last reviewed:** 2026-08-23T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2121
- **ID:** TL-2026-2121
- **Severity:** CRITICAL
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 17 (full data via the Threadlinqs MCP server — Purple tier)

## Description

isolated-vm is a widely used Node.js native addon that runs untrusted JavaScript inside separate V8 isolates and lets a host application exchange data with that guest code via ExternalCopy and ivm.Reference objects. Security researcher Cristian-Alexandru Staicu of Endor Labs found that ExternalCopy's constructor walks the caller-supplied transferList array twice: once to validate that every element is an ArrayBuffer, and a second time to actually transfer the elements, trusting the earlier validation without re-checking it. Because array element access can be intercepted with a JavaScript getter, an attacker who controls a single transferList entry can register a stateful getter that returns a genuine ArrayBuffer on the first (validating) read and an attacker-chosen value, such as the integer 0x41414141, on the second (transferring) read. The unchecked second read then performs an unsafe As<ArrayBuffer>() cast on that value inside ExternalCopyArrayBuffer::Transfer, producing a type confusion that dereferences an attacker-derived pointer, calling IsDetachable() and GetBackingStore() on corrupted memory and crashing the host at a fully attacker-controlled address (SIGSEGV at 0x4141414100000047 in the published PoC).

While the ExternalCopy constructor itself is host-only API surface, Endor Labs showed that a guest with nothing more than a single ivm.Reference -- the standard mechanism a host uses to expose any capability at all to a sandboxed isolate -- can reach ExternalCopy indirectly (e.g. via ref.getSync('key', {externalCopy:true}).constructor) and trigger the bug from inside the sandbox. Beyond the minimum demonstrated impact of a reliable, attacker-controlled-address crash (denial of service), Endor Labs privately escalated the primitive to a full control-flow hijack: recovering the host's ASLR base from pointers leaked through buffer operations, forging fake control-block/vtable structures in sprayed heap memory, and redirecting an indirect call read from that forged vtable into a chosen libc function -- i.e. weaponizing the type confusion into arbitrary native-code execution in the host process, outside the sandbox. The full RCE exploit chain was withheld from publication and shared privately with the maintainer. Staicu emphasized that the V8 Isolate boundary itself held -- the failure is in the memory-unsafe C++ glue code isolated-vm uses to marshal values across that boundary -- and that no transferList configuration exists that makes the flaw safe; only upgrading remediates it.

Every isolated-vm release through and including 7.0.0 is affected. The maintainer, Marcel Laverdet, shipped fixes in 6.2.0 (6.x line) and 7.0.1 (7.x line) that wrap ExternalCopy::Copy in a v8::Isolate::DisallowJavascriptExecutionScope, which prevents any user JavaScript -- including getters, proxies, and interceptors -- from running during the copy operation, removing the precondition the type confusion depends on. As of publication no CVE identifier had been assigned; the flaw is tracked solely as GHSA-864f-rcv7-6rh4, and it does not appear in the CISA Known Exploited Vulnerabilities catalog. No public exploit code has been released -- Endor Labs withheld full exploit details to prevent misuse -- and no in-the-wild exploitation has been reported.

Because isolated-vm is frequently the sole isolation boundary around a "run this untrusted/LLM-generated code" feature, the flaw has outsized blast radius: Endor Labs and downstream reporting identified n8n, Mastra, Activepieces, Sim.ai, Budibase, Directus, and Rocket.Chat as open-source projects that embed isolated-vm (Budibase and Directus both migrated to it from the deprecated vm2 sandbox), alongside production users including Fly.io, Algolia, TripAdvisor, and Screeps. ComplianceHub.Wiki's analysis of the disclosure lays out the concrete agentic-AI attack chain this creates: untrusted external content (a support ticket, a fetched web page, an uploaded PDF) reaches an LLM's context window, a prompt injection in that content causes the model to emit crafted JavaScript, the platform's sandbox executes that JavaScript, and the type confusion escalates it to host RCE -- because for platforms like n8n, Mastra, Sim.ai, and Activepieces, "running code that a model, or a user, generated" is the product's core function. The same analysis notes that the compromised host process typically holds the platform's own service credentials -- API keys, database connections, OAuth tokens, and cloud IAM roles the agent needs to do its job -- turning a sandbox escape into a credential-blast-radius incident that extends well beyond the code-execution boundary, and ties the exposure to ISO/IEC 42001 (A.6.2.4, A.6.2.6, A.5.2), SOC 2 (CC6.1, CC6.6, CC7.1), PCI DSS 4.0 (6.3.3, 6.2.4), and EU AI Act Article 15 control obligations for organizations running AI agent platforms on isolated-vm.

## MITRE ATT&CK

- AML.T0051 LLM Prompt Injection
- T1059.007 JavaScript
- T1106 Native API
- T1611 Escape to Host
- T1211 Exploitation for Stealth
- T1552 Unsecured Credentials
- T1499.004 Application or System Exploitation
- T1587.004 Exploits
- T1588.005 Exploits
- T1588.006 Vulnerabilities

## Sources

- [Critical Isolated-vm Vulnerability Leads to RCE on Host](https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/)
- [Isolated-vm Flaw Lets Sandboxed JavaScript Escape to Host for Potential RCE](https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html)
- [We discovered a critical vulnerability in isolated-vm, a sandbox that is widely used in popular AI-related projects](https://www.endorlabs.com/learn/ghsa-864f-rcv7-6rh4-critical-type-confusion-vulnerability-in-isolated-vm)
- [GHSA-864f-rcv7-6rh4: Type confusion in ExternalCopy results in guest-reachable memory corruption and control-flow hijack](https://github.com/laverdet/isolated-vm/security/advisories/GHSA-864f-rcv7-6rh4)
- [Critical Flaw in isolated-vm Can Lead to Sandbox Escape, RCE Threat](https://devops.com/critical-flaw-in-isolated-vm-can-lead-to-sandbox-escape-rce-threat/)
- [The Sandbox Was the Control: isolated-vm's Type Confusion Flaw and What It Breaks in AI Agent Governance](https://compliancehub.wiki/isolated-vm-sandbox-escape-ghsa-864f-ai-agent-code-execution-governance-2026/)
- [Isolated-vm Flaw Lets Sandboxed JavaScript Escape to Host for Potential RCE](https://www.guardianmssp.com/2026/08/20/isolated-vm-flaw-lets-sandboxed-javascript-escape-to-host-for-potential-rce/)
- [Self-Hosted Weekly: Week 34, 2026 -- Linux 7.2, isolated-vm Escape, Go 1.27](https://blog.elest.io/self-hosted-weekly-week-34-2026-linux-7-2-isolated-vm-escape-go-1-27/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2121