Critical isolated-vm Flaw Lets JavaScript Escape Sandbox, Hijack Host

Key Takeaways

• A critical vulnerability (GHSA-864f-rcv7-6rh4) in the Node.js library isolated-vm allows untrusted JavaScript to escape its sandbox.
• The flaw, impacting versions prior to 7.0.1 and 6.2.0, could lead to host process hijacking and arbitrary code execution.
• The vulnerability exploits a type-confusion issue within the ExternalCopy feature, specifically during the handling of transferList options.
• Fixes were released on August 8, 2026, and users are urged to upgrade immediately.

Critical isolated-vm Flaw Poses Sandbox Escape Risk

A severe security vulnerability has been identified in isolated-vm, a widely used Node.js library designed to sandbox untrusted JavaScript code. This flaw could enable malicious JavaScript to bypass its V8 sandbox and potentially gain control over the host process.

Technical Details of the Vulnerability

Designated as GHSA-864f-rcv7-6rh4 and currently awaiting a formal CVE identifier, this critical issue affects isolated-vm versions preceding 7.0.1 and 6.2.0. The maintainers addressed the vulnerability by releasing patched versions on August 8, 2026.

The core of the vulnerability lies within isolated-vm’s ExternalCopy feature, which facilitates data exchange between distinct V8 Isolates. V8 Isolates are fundamental to the sandboxing mechanism, ensuring each JavaScript environment operates with its own isolated heap, built-in objects, and object graph. This architecture is designed to prevent sandboxed code from directly interacting with host objects unless explicitly granted permission, typically through mechanisms like an ivm.Reference.

According to Endor Labs researchers, the integrity of the V8 isolation primitive itself remained intact. Instead, the flaw was pinpointed in the native C++ binding code responsible for managing data transfers across the isolation boundary.

Specifically, the vulnerability exploits the transferList option within ExternalCopy. This option is used to transfer ArrayBuffer memory directly, rather than copying it, to boost performance for large data structures. The problematic code iterates over the transfer list twice: first to validate that all entries are indeed ArrayBuffers, and then a second time to perform the actual transfer. Crucially, this second iteration fails to revalidate the types of the entries.

Exploitation Mechanism and Impact

An attacker can exploit this oversight by employing a JavaScript getter. During the initial validation pass, the getter returns a legitimate ArrayBuffer, allowing the validation to succeed. However, during the subsequent transfer pass, the same getter is manipulated to return a different, unexpected value, such as an integer or a string. The native C++ code then proceeds to treat this non-ArrayBuffer value as an ArrayBuffer due to an unchecked conversion, leading to a type-confusion error. This creates a time-of-check/time-of-use (TOCTOU) condition, where the state of an object changes between verification and use.

The resulting type confusion can cause the host process to attempt to dereference attacker-controlled memory-like data, leading to a crash and a denial-of-service condition. Beyond merely crashing the process, Endor Labs researchers demonstrated that this flaw can be escalated to achieve control-flow hijacking within the host process. This could ultimately enable arbitrary code execution outside the confines of the sandbox.

The attack can be initiated from within a sandboxed environment with only a single exposed IVM.Reference. This is significant because such references are commonly used to provide limited functionality to sandboxed scripts. By obtaining the ExternalCopy constructor via an exposed reference, an attacker can construct the malicious transfer list entirely from within the isolated environment.

This vulnerability presents a substantial risk for applications that execute untrusted or user-provided JavaScript, including multi-tenant platforms, AI agent systems, workflow automation tools, and user-script runners. Organizations utilizing isolated-vm for isolating automation scripts or model-generated code are strongly advised to review their deployments without delay.

What You Should Do

• Upgrade Immediately: All users of isolated-vm should upgrade to version 7.0.1 or 6.2.0 as soon as possible to mitigate this critical vulnerability.
• Limit Sandbox Capabilities: Review and minimize the capabilities exposed to sandboxed code through ivm.Reference objects. Grant only the absolute minimum necessary permissions.
• Audit Native Bindings: Conduct thorough security audits of any custom native binding layers or “glue code” that interacts with isolation primitives. Even robust isolation can be undermined by insecure surrounding code.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.