Critical Bug in isolated-vm Allows JavaScript to Break into Host Process

A serious vulnerability has been discovered in the Node.js sandboxing library isolated-vm, which could allow untrusted JavaScript to bypass its sandbox and seize control of the host process. The flaw, identified as GHSA-864f-rcv7-6rh4 and pending a finalized CVE designation, affects isolated-vm versions earlier than 7.0.1 and 6.2.0. Patched versions were released on August 8, 2026.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

What is isolated-vm? It’s a library used to create separate V8 engine instances (called Isolates), giving each sandboxed JavaScript environment its own memory heap, built-in objects, and object graph. These Isolates prevent sandboxed code from accessing any host-side objects unless those are explicitly exposed, such as via an ivm.Reference.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

How the Flaw Works
The flaw resides in the library’s ExternalCopy feature, which handles moving data between V8 Isolates. Specifically, the transferList option permits ArrayBuffer objects to be transferred (instead of copied), for performance gains. The bug emerges because the code first confirms every entry in the transferList is an ArrayBuffer, but then, in a second pass, transfers them without rechecking their types—opening a window for misuse.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

An attacker can exploit this behavior using a JavaScript getter: on the first validation loop, the getter returns a bona fide ArrayBuffer, satisfying type checks. By the second loop, however, it returns a non-ArrayBuffer value (like a string or integer). Due to the unchecked conversion, the system processes that value as if it were an ArrayBuffer. This mismatch leads to a classic TOCTOU (time-of-check/time-of-use) vulnerability and a type confusion issue. In worst-case scenarios, it permits dereferencing arbitrary memory, possibly enabling execution of foreign code outside the sandbox. At minimum, it can crash the host and trigger denial-of-service.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

Who’s at Risk?
Any application that embeds isolated-vm to run third-party JavaScript code—or uses user-provided scripts—stands exposed. That includes multi-tenant cloud services, AI agent platforms, workflow automation tools, and script-runners. Even sandboxed environments with just one exposed ivm.Reference become attack vectors, because through this reference an attacker could access the ExternalCopy constructor and build a malicious transferList entirely from within the sandbox.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

What’s Fixed and What to Do
The maintainers’ fix prevents JavaScript execution (getters, proxies, etc.) from altering values between validation and transfer operations, eliminating the time-of-check/time-of-use gap in ExternalCopy. To address the issue, users must upgrade to isolated-vm version 7.0.1 or 6.2.0. Beyond patching, organizations are urged to restrict the host objects exposed to sandboxed code and scrutinize native binding layers, since even strong sandbox primitives can be compromised by unsafe glue code.([cybersecuritynews.com](https://cybersecuritynews.com/critical-isolated-vm-flaw/))

This vulnerability underscores a recurring theme: sandboxing or isolation mechanisms are only as secure as every layer around them—including the native bindings and transfer logic. The isolated-vm library is intended to provide strong isolation, but the external glue that bridges JavaScript and native C++ code introduced a fragile gap.

Why This Matters
This isn’t just academic. Host process hijacking breaks one of the most important promises of sandboxes: keeping untrusted code from impacting the rest of a system. For cloud platforms, code runners, or AI environments where you often run someone else’s script, the intrusion risk becomes real. Every exposed reference—even just one—can be enough to break isolation.

What to Watch Next
Watch how quickly dependent frameworks and platforms adopt the patched versions. Also scrutinize native binding layers and transfer mechanisms in similar sandboxing technologies—this flaw could hint at broader issues elsewhere. As isolation becomes ever more critical in AI, cloud, and multi-tenant apps, even tiny cracks can deliver massive leverage to attackers.