Critical Flaw in 'isolated-vm' Node.js Sandbox Exposes Host Systems to Memory Corruption, RCE
A significant security vulnerability has been uncovered in **isolated-vm**, a widely used Node.js library designed for sandboxing untrusted JavaScript. The flaw could allow attackers to escape the isolated environment, leading to memory corruption and potential remote code execution on the host system. IT security professionals and developers are urged to update immediately.
Cybersecurity researchers have disclosed a critical security flaw in **isolated-vm**, a popular open-source sandbox with more than 2,900 stars and 190 forks on GitHub, that could allow attackers to escape the confines of the isolated environment.
The vulnerability (**GHSA-864f-rcv7-6rh4**), which has yet to be assigned a CVE identifier, impacts all versions of the library before and including 7.0.0. It has been patched in versions 6.2.0 and 7.0.1 released earlier this month.
**isolated-vm** is a **Node.js** library for running untrusted JavaScript inside a **V8 Isolate**, an independent instance of the Google V8 JavaScript engine, allowing multiple sandboxed JavaScript environments to run concurrently without sharing data or interfering with each other. The npm package has witnessed nearly 1 million downloads over the past week.
### Understanding the Vulnerability
Because each **V8 Isolate** has a separate state and maintains its own heap, it is not possible to directly pass JavaScript objects from the main **Node.js** thread into a worker isolate. **isolated-vm** exposes a class called **ExternalCopy** to securely serialize JavaScript objects out of the host isolate and deserialize them into the guest isolate.
The vulnerability identified by **Endor Labs** resides in this component, allowing code running inside the sandbox to break out and corrupt memory in the host application.
"A type confusion in **ExternalCopy**'s handling of the `transferList` option lets code running inside the sandbox corrupt memory in the host process," **Endor Labs** researcher **Cristian-Alexandru Staicu**, who is credited with discovering and reporting the flaw, said in a technical write-up shared with The Hacker News.

"Starting from nothing but a single `ivm.Reference`, the standard way hosts hand a sandbox any capability at all, we escalated the bug from a controlled-address crash all the way to hijacking the host's control flow, demonstrating a full guest-to-host sandbox escape."
### Impact and Remediation
Successful exploitation of the flaw allows memory corruption in the host process, causing the host process to crash with a segmentation fault (**SIGSEGV**). It can also lead to a guest-to-host sandbox escape and an erosion of the trust boundary that undermines the very purpose of **isolated-vm**.
"Minimum demonstrated impact is a reliable, controlled-address crash (denial-of-service) triggerable by any guest that has been given an `ivm.Reference` (the standard way to grant a sandbox any capability)," project maintainer **Marcel Laverdet** said in an advisory.
"Maximum demonstrated impact is control-flow hijack of the host process, i.e., potential remote code execution in the host."
Users who have **isolated-vm** installed in their developer environments are advised to update to the latest version for optimal protection. Additional details of the full exploit have been withheld so as to prevent bad actors from launching their own attacks.
"The most important takeaway is that what was not broken was the isolation primitive itself," **Staicu** said. "**V8**'s Isolate boundary held. What failed was the C++ glue code that marshals values across that boundary. A perfectly sound building block was undermined by the binding layer wrapped around it."