A popular JavaScript sandbox has a hole in it, and the fix is to stop using it
Researchers found a way out of isolated-vm, an open-source tool used to safely run untrusted code. The maintainer says the project is unmaintained and users should migrate.
Key points
- Researchers disclosed a critical flaw in isolated-vm, an open-source JavaScript sandbox used by more than 2,900 projects on GitHub.
- The bug, tracked as GHSA-864f-rcv7-6rh4, affects every version up to and including 7.0.0.
- A successful escape lets attacker-controlled JavaScript run on the host machine, not just inside the sandbox.
- No CVE number has been assigned yet, and no patched version is available.
- The project's maintainer has flagged isolated-vm as unmaintained, meaning teams need to plan a migration rather than wait for a fix.
A widely used piece of software that is supposed to keep dangerous code locked in a box has a hole in the box.
The tool is called isolated-vm. It is a library that lets a program run someone else's JavaScript code in a walled-off area, so that the code cannot touch the rest of the system. Cloud platforms, plugin systems and online code editors reach for it when they need to run code they do not trust.
Security researchers, in reporting first surfaced by The Hacker News, have now shown that the walls are not solid. The flaw is tracked as GHSA-864f-rcv7-6rh4, and it affects every release up to and including version 7.0.0.
What can an attacker actually do?
Break out of the sandbox and run code on the host. That is the whole point of a sandbox escape: the attacker submits JavaScript that is meant to be contained, and instead the code executes with the same access as the application running isolated-vm. In practice that can mean reading secrets, touching other tenants' data, or pivoting deeper into a cloud environment.
The failure mode here is the one every platform team dreads. You built a multi-tenant service on the assumption that the sandbox holds. It does not.
Who uses this library?
A lot of people. The GitHub repository has more than 2,900 stars and 190 forks, and it is a common building block anywhere a service needs to execute customer-supplied JavaScript. Serverless-style products, low-code tools, chatbot platforms and internal automation systems have all pulled it in over the years.
If your engineering team runs untrusted JavaScript anywhere, ask them today whether isolated-vm is in the dependency tree.
Is there a patch?
No. That is the awkward part. The advisory covers all versions through 7.0.0, no fixed release has shipped, and no CVE identifier has been assigned yet. The maintainer has also indicated the project is no longer actively maintained, which means waiting for a patch is not a plan.
The practical answer is migration. Move workloads to a stronger boundary: a separate process with tight system call limits, a container with a hardened runtime like gVisor, a lightweight virtual machine such as Firecracker, or a WebAssembly runtime designed for untrusted code. Each of these puts a real operating-system or hardware barrier between the guest code and your host, rather than relying on tricks inside a single Node.js process.
Facts at a glance
| Item | Detail |
|---|---|
| Library | isolated-vm |
| Advisory ID | GHSA-864f-rcv7-6rh4 |
| Affected versions | All versions up to and including 7.0.0 |
| CVE ID | Not yet assigned |
| Fix available | No; project flagged as unmaintained |
| GitHub reach | 2,900+ stars, 190+ forks |
What should ordinary users do?
Nothing directly. This is a supply-chain problem for the companies whose services you use, not something you patch on your phone. If a platform you rely on runs customer scripts or plugins, expect brief outages or feature pauses over the next few weeks as engineering teams rip out isolated-vm and replace it.
One thing the post-mortem will say: sandboxes built inside a single language runtime age badly. Put the boundary at the operating system, or somewhere lower.
