A critical vulnerability in isolated-vm, the Node.js library that platforms use to run untrusted JavaScript inside a genuine V8 Isolate rather than a same-process sandbox, allows code executing inside the isolate to corrupt memory in the host process and achieve a full guest-to-host escape. The flaw is tracked as GHSA-864f-rcv7-6rh4 (CVE assignment pending) and was disclosed August 20 by Endor Labs researcher Cristian-Alexandru Staicu. It matters well beyond the package’s own footprint: isolated-vm sits underneath the untrusted-code execution paths of several widely deployed automation and AI-agent platforms, including n8n, Activepieces, and Mastra.

What happened

isolated-vm exists precisely to solve the problem that plain V8 vm contexts don’t provide real isolation — it spins up a separate V8 Isolate with its own heap, and code inside it can only interact with the host through explicit, narrow bridges such as ivm.Reference and ivm.ExternalCopy. ExternalCopy is the mechanism for copying a JavaScript value out of the isolate and into the host (or vice versa), and it accepts a transferList option to control which values are transferred by reference rather than deep-copied.

The vulnerability lives in the native C++ glue code that implements ExternalCopy::Copy. The transferList argument is read via a JavaScript getter, and nothing prevented that getter — or a Proxy, or an interceptor — from running arbitrary guest-controlled JavaScript in the middle of the native copy operation. By defining a malicious getter on an object passed as transferList, code inside the sandbox can mutate the underlying data structures the native code is mid-way through processing, producing a type confusion between what the C++ layer expects and what’s actually in memory at that point. Endor Labs’ writeup describes escalating from a single ivm.Reference all the way to a controlled-address crash and then to full control-flow hijacking in the host process — a complete break of the isolation boundary the library exists to provide.

The fix wraps ExternalCopy::Copy in a v8::Isolate::DisallowJavascriptExecutionScope, which categorically prevents any guest JavaScript — getters, proxies, interceptors — from executing during the native copy. That removes the shared precondition the exploit chain depended on.

Technical details

  • GHSA-864f-rcv7-6rh4 — type confusion in isolated-vm’s ExternalCopy handling of the transferList option, enabling guest-to-host sandbox escape. CVE assignment pending at time of writing.
  • Root cause: the native ExternalCopy::Copy binding invokes a JS-controlled getter for transferList without disallowing JS execution during the copy, letting guest code re-enter and corrupt host-side memory mid-operation.
  • Affected: all isolated-vm versions up to and including 7.0.0.
  • Fixed in: 6.2.0 and 7.0.1, released earlier this month.
  • Exploitation primitive: starts from a single ivm.Reference held by guest code; escalates to arbitrary memory corruption and control-flow hijacking in the host process — no additional host-side misconfiguration required.
  • Discoverer: Cristian-Alexandru Staicu, Endor Labs.

Impact

isolated-vm sees close to a million weekly npm downloads and is the recommended isolation primitive for several categories of platforms that execute code they did not write:

  • n8n uses it in sandboxed task runners for user-authored Code-node scripts and explicitly recommends it as the hardened isolation option over its default vm2-style execution.
  • Activepieces uses it to sandbox the JavaScript inside automation “pieces,” restricting them to browser-like semantics with no Node.js API surface.
  • Mastra, an AI agent framework, uses it in “code mode” to execute model-generated tool-orchestration code inside a real V8 isolate — meaning an LLM-authored snippet, or a snippet an attacker manipulated an LLM into generating via prompt injection, runs directly against this boundary.

For all of these, the entire security model rests on the assumption that isolate boundaries hold. A working guest-to-host escape means untrusted user scripts, third-party workflow “pieces,” or LLM-generated code can pivot from the sandbox to full code execution on the host running the orchestration platform — with access to whatever secrets, network position, and downstream integrations that host holds. In AI-agent deployments specifically, this closes the gap between “the model generated something malicious” and “that something now runs unconstrained,” which is the exact failure mode agent sandboxing is supposed to prevent.

Mitigation

  • Upgrade isolated-vm to 7.0.1 (or 6.2.0 on the older line) immediately. There is no configuration workaround — the vulnerable code path is core to how ExternalCopy operates.
  • Audit transitive dependencies. Teams don’t always depend on isolated-vm directly; check whether an automation platform, AI agent framework, or internal sandboxing layer pulls it in and confirm the vendor has shipped a patched release.
  • Treat any workload that runs LLM-generated or third-party-authored code through isolated-vm as having been unisolated until patched — review logs for anomalous host-process behavior on affected task runners during the exposure window.
  • Don’t rely on process-level sandboxing alone for genuinely untrusted code. Pair language-level isolates with OS-level controls (containers, gVisor, microVMs) where the threat model includes arbitrary or adversarially-generated code, since this is not the first V8-isolate escape and won’t be the last.

Sources: Endor Labs — Critical Type Confusion Vulnerability in isolated-vm, The Hacker News — Isolated-vm Flaw Lets Sandboxed JavaScript Escape to Host for Potential RCE, GitHub Security Advisory GHSA-864f-rcv7-6rh4.