Critical isolated-vm Flaw Lets Untrusted JavaScript Escape Sandbox and Hijack Host Execution

A critical security flaw in the popular Node.js sandboxing library isolated-vm could allow untrusted JavaScript to escape its V8 sandbox and potentially hijack execution in the host process.

The issue, tracked as GHSA-864f-rcv7-6rh4 and awaiting a CVE identifier, affects isolated-vm versions earlier than 7.0.1 and 6.2.0. The maintainers released fixes on August 8, 2026.

The vulnerability exists in ExternalCopy, a feature used by isolated-vm to move data between separate V8 Isolates. V8 Isolates are designed to separate JavaScript environments by giving each sandbox its own heap, built-in objects, and object graph.

This prevents sandboxed code from directly accessing host objects unless the host intentionally exposes a capability, such as an ivm.Reference.

Endorlabs researchers found that the V8 isolation primitive itself was not broken. Instead, the flaw was located in native C++ binding code responsible for transferring data across the isolation boundary.

The issue involves the transferList option used by ExternalCopy. This option allows ArrayBuffer memory to be transferred rather than copied, improving performance for large buffers.

During processing, the affected code iterates over the transfer list twice. The first iteration verifies that every entry is an ArrayBuffer. The second iteration transfers the same entries but does not revalidate their types.

Critical isolated-vm Flaw

An attacker can exploit this gap through a JavaScript getter. During the first read, the getter returns a valid ArrayBuffer, allowing validation to succeed.

During the second read, it returns a different value, such as an integer or string. The native code then treats that unexpected value as an ArrayBuffer through an unchecked conversion.

This creates a type-confusion flaw and a time-of-check/time-of-use, or TOCTOU, condition. The host process can then dereference attacker-controlled memory-like data, causing a crash.

According to Endor Labs researchers, this flaw can be escalated beyond denial-of-service attacks to hijack the host process’s control flow.

The attack can be triggered from inside a sandbox with only one exposed IVM.Reference. That is important because references are commonly used to provide limited functionality to sandboxed scripts.

By retrieving the ExternalCopy constructor through an exposed reference, an attacker can build the malicious transfer list entirely from within the isolated environment.

The minimum impact is a crash of a reliable host process, creating a denial-of-service condition. The maximum demonstrated impact is control-flow hijacking in the host process, which could lead to arbitrary code execution outside the sandbox.

The risk is significant for multi-tenant applications, AI agent platforms, workflow automation tools, user-script runners, and services that execute customer-provided JavaScript.

Products that use isolated-vm to isolate automation scripts or model-generated code should review their deployments immediately.

The maintainers fixed the issue by preventing JavaScript execution while ExternalCopy performs the sensitive copy operation. This blocks getters, proxies, and similar mechanisms from changing values between validation and transfer.

Organizations should upgrade to isolated-vm 7.0.1 or 6.2.0 as soon as possible. Security teams should also reduce the capabilities shared with sandboxed code and audit native binding layers, because a strong isolation primitive can still be undermined by unsafe glue code around it.

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