Critical Sandbox Escape in isolated-vm
Cybersecurity researchers have disclosed a critical security flaw in isolated-vm, a widely used open-source Node.js library that provides isolated JavaScript execution environments. The vulnerability, tracked as GHSA-864f-rcv7-6rh4, allows attacker-controlled code running inside the sandbox to escape the isolated context and execute arbitrary code on the underlying host.
The library has over 2,900 stars and 190 forks on GitHub and is commonly used by platforms that need to safely execute untrusted JavaScript — including plugin systems, online code editors, and serverless compute environments.
What Is isolated-vm?
isolated-vm is a Node.js native addon built on V8's Isolate API. It is designed to run untrusted JavaScript in a memory-isolated environment, preventing sandboxed code from accessing the host process's memory, file system, or network. It is a popular choice for:
- Plugin/extension systems that allow user-submitted code
- Online coding platforms and REPLs
- Multi-tenant serverless execution environments
- AI agent sandboxes running generated code
The Vulnerability
The disclosed flaw bypasses the isolation boundary enforced by isolated-vm, allowing JavaScript running inside the sandbox to break out into the host V8 context. From there, an attacker can leverage Node.js APIs to achieve full Remote Code Execution (RCE) on the host machine with the privileges of the process running isolated-vm.
The vulnerability has not yet been assigned a CVE as of the advisory publication date, suggesting it may still be in the coordination or disclosure process.
Technical implications:
- Any platform executing untrusted JavaScript via isolated-vm is potentially exposed
- The escape does not require prior access to host resources — it can be triggered entirely from within the sandbox
- Applications that treat isolated-vm as a security boundary may be critically compromised
Who Is at Risk?
Organizations and developers most at risk include:
- SaaS platforms offering user-defined scripting or automation
- Code execution services (online IDEs, competitive programming platforms)
- AI/LLM application frameworks that sandbox generated code
- CMS and e-commerce platforms with plugin execution features
If your application allows untrusted parties to submit JavaScript code that runs through isolated-vm, treat this as a critical exposure until a patch is available.
Recommended Actions
Until a fixed version is released:
- Assess your exposure — determine if your application executes code from untrusted parties via isolated-vm
- Apply defense-in-depth — run isolated-vm processes in sandboxed OS containers (Docker, gVisor, Firecracker) with restricted syscalls and no network access
- Monitor for a patch — watch the isolated-vm GitHub repository for security releases
- Consider alternatives — evaluate whether a process-level sandbox (subprocess with seccomp/AppArmor) may be more appropriate for your threat model
- Audit existing deployments for signs of unexpected file access, process spawning, or outbound network connections from sandboxed environments
Broader Context
Sandbox escapes in JavaScript VMs have a long history — from browser-based V8 exploits to Node.js-specific bypasses. The lesson is consistent: no userspace sandbox should be treated as the sole security boundary when executing fully untrusted code. OS-level isolation (containers, VMs, seccomp filters) must complement any VM-level sandbox.