Researchers have disclosed a critical Isolated-vm escape flaw affecting a widely used Node.js sandbox library. If exploited, malicious code running inside the sandbox may be able to break out and affect the host application—meaning the very isolation users rely on could be weakened.
The issue has been tracked under GHSA-864f-rcv7-6rh4 and, at the time of disclosure, did not yet have an assigned CVE identifier. The vulnerable code applies to versions up to and including 7.0.0, while fixes are included in 6.2.0 and 7.0.1, which were released earlier that month.
What isolated-vm does—and why it matters
Isolated-vm is an open-source library designed to run untrusted JavaScript safely. It works by leveraging a V8 Isolate, which represents an independent instance of the V8 JavaScript engine. This isolates execution environments so multiple sandboxed JavaScript contexts can run concurrently without sharing data directly or interfering with one another.
A key design point is that isolates do not share JavaScript object state. Because of how V8 isolates are set up, it’s not possible to simply pass JavaScript objects from the main Node.js thread into a worker isolate in a direct way.
To bridge this gap, isolated-vm exposes an ExternalCopy class. This component handles secure serialization of JavaScript values from the host isolate and their deserialization inside the guest isolate, enabling controlled data transfer across the boundary.
The core problem: type confusion in ExternalCopy
According to Endor Labs researchers, the vulnerability is tied to how ExternalCopy processes a specific option named transferList. In their write-up, they describe a type confusion condition that could allow code in the sandbox to corrupt memory in the host process.
In other words, the sandboxed code does not only misbehave within its own limits; it may be able to manipulate how values are handled across the bridge layer. That bridge layer is implemented in C++ glue code, which converts and marshals data between isolate boundaries.
The researcher credited with discovering and reporting the flaw, Cristian-Alexandru Staicu, explained that exploitation could be escalated from a controlled-address crash to hijacking the host’s control flow. Their findings demonstrate a full guest-to-host sandbox escape path under the conditions described in the advisory.
From denial of service to possible remote code execution
Not every exploit path needs to be equally severe to be dangerous. In this case, both the minimum and maximum demonstrated impacts were reported.
The project maintainer, Marcel Laverdet, stated that the minimum demonstrated impact is a reliable crash. Specifically, a compromised guest can trigger memory corruption that results in the host process crashing with a segmentation fault (SIGSEGV). This is effectively a denial-of-service scenario.
They also described a maximum demonstrated impact: control-flow hijack of the host process. That is the kind of outcome that can translate into potential remote code execution (RCE) on the host, depending on deployment context and exploit conditions.
It’s important to note that the boundary issue is not framed as a failure of the isolation primitive itself. Instead, the concern is the correctness and safety of the data marshaling logic around the isolate boundary.
Why the isolation boundary can be undermined
To understand how this matters, it helps to separate two parts of the system: the V8 isolate boundary and the glue code that transfers capabilities and values across it.
Staicu emphasized that what was not broken was the isolate boundary: V8’s isolate boundary itself held. The failure occurred in the C++ glue code that marshals values across that boundary. Even a sound “building block” can become risky if the connection layer is vulnerable.
In practical terms, isolated-vm gives sandboxed code a way to receive capabilities via ivm.Reference—which is described as the standard way hosts grant a sandbox any capability at all. The advisory highlights that the vulnerability’s impact is tied to situations where the sandbox has been provided such a reference.
Who should update—and what versions are fixed
If you use isolated-vm in your development environment or in production services, you should treat this as an urgent update issue. The safest path is to move to patched releases.
Based on the reported advisory:
- Vulnerable: all versions before and including 7.0.0
- Patched: 6.2.0 and 7.0.1
Updating to the latest version provides the most reliable protection against the specific conditions that enable the memory corruption behavior described in the reports.
Exploit details withheld to reduce misuse
While the security community benefits from transparency, disclosures also need to avoid enabling copycat attacks. In this case, additional details of the full exploit were withheld so that bad actors could not immediately weaponize the bug.
The key takeaway for defenders is still clear: the risk is tied to how certain transfer parameters are handled in the ExternalCopy component. Organizations should focus on patching, reviewing dependency versions, and ensuring sandboxed execution is only granted the minimum necessary capabilities.
Practical next steps for teams using isolated-vm
Beyond updating, consider these actions to reduce exposure:
- Audit your dependency tree to confirm which isolated-vm version is installed across environments.
- Update immediately to a fixed release (6.2.0 or 7.0.1, and beyond where applicable).
- Review capability exposure—since ivm.Reference is described as the standard capability mechanism, ensure you only grant what the sandbox truly needs.
- Monitor for crashes and unusual host behavior during sandboxed execution, especially in systems that process untrusted inputs.
Even though the isolate boundary itself is described as holding, vulnerabilities in the bridge code can still create a route to host instability or more severe outcomes.
Conclusion
The Isolated-vm escape flaw is a serious reminder that sandboxing security depends not only on the isolation technology, but also on the correctness of the interfaces and glue code around it. Researchers reported that a type confusion issue in ExternalCopy could enable memory corruption and a sandbox escape path under certain conditions.
With fixes available in 6.2.0 and 7.0.1, the most effective response is to update promptly. If you run isolated-vm today, check your installed version and patch without delay to protect the host process.
Source: https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
