A recently disclosed isolated-vm type confusion issue highlights how subtle bugs in sandbox boundary code can undermine isolation. Researchers report a critical-severity flaw that may allow an attacker to reach remote code execution (RCE) on the host system, depending on how developers integrate isolated-vm and how untrusted code interacts with host-provided references.
In this article, we break down what isolated-vm does, what went wrong in the ExternalCopy flow, and which mitigations are available in patched versions.
What isolated-vm is designed to do
isolated-vm is a Node.js library built to run JavaScript in strongly separated environments. Under the hood, it exposes V8’s Isolate interface, which represents an independent V8 execution context.
Each Isolate provides its own heap memory, execution state, and garbage collection. As a result, multiple isolated JavaScript instances can run on the same machine while staying separated—without requiring a full container or virtual machine.
Because isolated-vm is commonly used to execute untrusted JavaScript, the security model relies heavily on the correctness of the boundary between host and sandbox.
The vulnerability: type confusion in ExternalCopy
The reported problem is a type confusion flaw that affects ExternalCopy, a function used to copy data across isolates. According to EndorLabs, ExternalCopy works by serializing data in one Isolate and then reconstructing it in another.
To improve performance, the copy process may accept a transferList. When large ArrayBuffer objects are involved, the implementation can transfer underlying memory by detaching the buffer from the source and handing it to the destination.
This design, while beneficial for speed, increases the importance of precise and consistent handling of the elements in transferList during reconstruction.
How transferList enables a TOCTOU-style weakness
The crux of the issue is tied to how the reconstructor walks the byte-array list during the transfer. Researchers describe that the code iterates over the relevant list twice, and the second iteration trusts the results from the first.
However, the security assumption breaks because accessing the transferList elements through JavaScript can behave differently across passes. Specifically, when list elements are represented using getters, iterating the JavaScript array for a second time may not yield the same value as during the first pass.
That mismatch creates a window resembling a time-of-check/time-of-use (TOCTOU) problem: a value can be checked one way, then used later under different conditions. In this case, the behavior can allow dereferencing an attacker-controlled pointer.
Why the host could be affected even when only passing a value
The ExternalCopy constructor is described as being accessible from the host side only. Yet the reports indicate a guest (the sandboxed code) can still influence exploitation by targeting ivm.Reference.
ivm.Reference is the mechanism through which the host exposes objects—or capabilities—into the sandbox. By abusing this, an attacker can build a malicious transferList and then trigger the vulnerability through the copy path.
In other words, the guest’s goal is not necessarily to directly call privileged constructors, but to cause the host’s copy logic to act on attacker-influenced data.
Impact: crash or control-flow hijack
If exploitation succeeds, the outcome is described as either:
- Denial-of-service through a crash, or
- Control-flow hijack of the host process
Researchers further note that, in the worst case, this could enable RCE on the host. The practical risk depends on whether an embedder (the application integrating isolated-vm) runs untrusted code and shares even a single reference into the isolate.
As the advisory emphasizes, the affected scenario includes host code that passes a caller-influenced array as transferList. Even if the guest can’t call the constructor directly, passing the crafted array through the host’s code path can still matter.
What the patch changes
EndorLabs reports that patches were included in isolated-vm 6.2.0 and isolated-vm 7.0.1.
The key mitigation described is preventing user JavaScript from running during the copy operation. Since the risky behavior hinges on JavaScript execution patterns during reconstruction, blocking that execution reduces the attacker’s ability to trigger the inconsistent getter behavior.
Researchers also point to the underlying cause living in the native glue layer: the C++ binding that serializes and reconstructs values across the isolate boundary. This layer handles low-level V8 handles and backing-store pointers.
The report explains that, during a security-sensitive operation, this native layer can re-read objects influenced by an attacker, and an unchecked cast on a re-read value can turn what should be an isolation primitive into a full escape.
What embedder teams should do now
If you integrate isolated-vm in an environment that runs untrusted JavaScript, this advisory should be treated seriously. Even a single exposed reference can increase exposure, and the transferList pathway can amplify risk.
Practical next steps include:
- Update isolated-vm to versions that include the fixes (6.2.0 or 7.0.1, as reported).
- Review how transferList is built, especially where it contains buffers or arrays influenced by callers or sandboxed inputs.
- Audit exposed references—the boundary objects shared with the sandbox are part of the threat surface.
- Test isolation assumptions with realistic workloads that include untrusted code paths, including any code that might use getters.
While the details focus on ExternalCopy and transferList, the broader lesson is clear: when code crosses isolation boundaries, native implementations must not rely on assumptions that attackers can violate through JavaScript execution behavior.
Broader context: sandboxing is only as strong as its glue
The isolated-vm type confusion report underscores a pattern seen across modern security research. Sandboxes often appear robust at the API level, but the real risk can hide in the native components that marshal data between environments.
When low-level code re-reads attacker-influenced objects during a sensitive operation, it can introduce subtle inconsistencies. Those inconsistencies may then become exploitable through timing and evaluation differences—exactly the kind of situation described here with a TOCTOU-style mismatch.
For developers, this is an argument for defense-in-depth: keep dependencies current, minimize what you expose to untrusted code, and validate that boundary operations can’t be influenced in surprising ways.
Conclusion
The newly identified isolated-vm type confusion vulnerability describes a critical issue in ExternalCopy that could allow attackers to achieve RCE on the host system. By manipulating how transferList elements are evaluated across multiple passes, threat actors may exploit a TOCTOU weakness and trigger unsafe pointer handling in native code.
Fortunately, patches are available in isolated-vm versions 6.2.0 and 7.0.1. If your application embeds isolated-vm and runs untrusted JavaScript, upgrading and auditing transferList usage and reference sharing should be an urgent priority.
Source: https://www.securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host/
