Critical isolated-vm Flaw Lets Attackers Escape Sandbox and Hijack Host Control Flow

A critical vulnerability has been discovered in the widely used Node.js sandboxing library, isolated-vm. This flaw could potentially allow untrusted JavaScript to escape its V8 isolate and hijack control flow in the host process.

The issue is tracked as GHSA-864f-rcv7-6rh4 and is awaiting CVE assignment. It affects isolated-vm versions before 7.0.1 and 6.2.0.

Researchers have demonstrated that an attacker with access to a single ivm.Reference, commonly used by hosts to expose limited capabilities to sandboxed code, can trigger host-process memory corruption, cause reliable denial of service, and create a pathway to control-flow hijacking.

Type Confusion in ExternalCopy

The vulnerability is rooted in the ExternalCopy mechanism of isolated-vm, which transfers data between V8 isolates. Since V8 isolates have independent heaps and do not share an object graph, values must be serialized and reconstructed when crossing the guest-host boundary.

ExternalCopy supports a transferList option that allows ArrayBuffers to be transferred without copying their underlying memory. However, researchers found that the library processes the supplied transfer list twice.

During the first iteration, isolated-vm verifies that each item is an ArrayBuffer. In the second iteration, it transfers each item without repeating the validation check.

This vulnerable code performs an unchecked As<ArrayBuffer>() conversion, effectively trusting that the second read returns the same object previously validated.

This assumption fails when the attacker supplies a JavaScript getter. Since reading array elements can invoke user-controlled accessors, the getter can return a legitimate ArrayBuffer during validation and then return a different value in the second pass.

let reads = 0;
Object.defineProperty(transferList, 0, {
  enumerable: true,
  get() {
    return ++reads === 1 ? real : 0x41414141;
  }
});

This creates a time-of-check/time-of-use (TOCTOU) vulnerability. The unchecked value is treated as an ArrayBuffer by native C++ code, leading to an attacker-controlled memory dereference.

Researchers demonstrated that a sandboxed guest could access the vulnerable ExternalCopy constructor using just one exposed ivm.Reference. This is significant because References are commonly used to provide controlled access to host-side functionality.

A proof of concept causes the host process to crash with SIGSEGV in v8::ArrayBuffer::IsDetachable when using an attacker-controlled address. While this controlled crash alone enables denial-of-service attacks, the research team further escalated the flaw.

By using a JavaScript string as the confused object, attackers can manipulate bytes interpreted as native object fields. The flawed transfer cleanup path eventually performs an indirect call through a vtable pointer, creating a primitive for control-flow hijacking.

Researchers from EndorLabs have reported demonstrating host execution redirection to a chosen libc function, although full exploit details are withheld.

The isolated-vm library is used in systems that execute user- or model-generated JavaScript, such as automation, AI agents, low-code platforms, and multi-tenant script-running environments. Projects identified by the researchers include n8n, Activepieces, Mastra AI, Budibase, Sim.ai, Directus, and Rocket.Chat.

It is important to note that the vulnerability does not compromise the security model of V8’s isolates. Instead, it undermines the C++ binding layer responsible for data marshaling across the boundary, illustrating how unsafe native glue code can weaken an otherwise robust isolation primitive.

The maintainer has released fixes in isolated-vm versions 7.0.1 and 6.2.0. The patch implements a v8::Isolate::DisallowJavascriptExecutionScope during the copy operation, preventing getters, proxies, and other JavaScript callbacks from executing while ExternalCopy handles sensitive data.

Organizations using isolated-vm should upgrade immediately, minimize the number of References shared with untrusted code, and audit for potential influence of attacker-controlled data on ExternalCopy or transferList handling.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC