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 library that's supposed to keep dangerous code locked in a box has a hole in the box.
The tool is called isolated-vm. It lets a program run someone else's JavaScript in a walled-off area so that code can't touch the rest of the system. Cloud platforms, plugin systems and SaaS code editors reach for it when they need to run code they don't trust. Sandbox escapes in this space aren't new to us: we've covered sixteen of them in the last 90 days, including the n8n escape in July that let workflow editors run commands on the server.
Now isolated-vm itself has one. The flaw, first reported by The Hacker News, is tracked as GHSA-864f-rcv7-6rh4 and 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's the whole point of a sandbox escape: the attacker submits JavaScript that's meant to be contained, and instead it 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.
This is the failure mode every platform team dreads. You built a multi-tenant service on the assumption that the sandbox holds. It doesn't.
Who uses this library?
More people than you'd expect. The GitHub repository has more than 2,900 stars and 190 forks. Serverless-style products, low-code tools 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. The advisory covers all versions through 7.0.0, no fixed release has shipped, and no CVE identifier has been assigned. The project's also been flagged as no longer actively maintained, so waiting for a patch isn't a plan.
Migrate. Move workloads to a stronger boundary: a separate process with tight system call limits, a container with a hardened runtime like gVisor, or a lightweight virtual machine such as Firecracker. Each of these puts a real operating-system 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 |
Should you worry?
Not directly, if you're an ordinary user. 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 as engineering teams replace isolated-vm.
The postmortem on this one will say what they always say: sandboxes built inside a single language runtime age badly. Put the boundary at the operating system, or somewhere lower. Vendors who shipped isolated-vm as a security control and called it done were selling you a promise the architecture couldn't keep.
