SURIQ
A JavaScript sandbox is a promise: run someone else's code, keep it away from your host. A newly disclosed flaw in isolated-vm, the library that keeps that promise for around a million projects every week, breaks the promise. Code that was meant to stay inside the box can reach into the host process, corrupt its memory, and in the researchers' proof, redirect the program to run whatever the attacker chose. The library is the containment layer under a growing set of self-hosted AI automation tools. That is where an abstract V8 bug turns into an operations problem you own.
Endor Labs researcher Cristian-Alexandru Staicu reported the issue as GHSA-864f-rcv7-6rh4, a CVE is still pending, and rated it critical. The Hacker News and SecurityWeek both reported the disclosure. isolated-vm runs untrusted JavaScript inside a separate V8 isolate, and it is a popular way for Node.js applications to execute code they do not trust.
What the flaw lets an attacker do
The bug is a type confusion in how isolated-vm copies data across the sandbox boundary, specifically in the way its ExternalCopy component handles the transferList option. Per the Endor Labs writeup, the constructor walks that list twice: the first pass validates each entry, the second pass performs the transfer without checking again. Because the list is a plain JavaScript array, a property read can return one value to the validating pass and a different value to the transfer pass. That gap between check and use is enough to hand the host a value it never verified, which the researchers escalated from a controlled crash all the way to control-flow hijacking.
Impact runs from a denial-of-service crash at the low end to remote code execution on the host at the high end. The researchers withheld a full proof-of-concept, and there are no reports of exploitation in the wild at the time of writing. Here is the version math a defender needs:
- 7.x line: 7.0.0 and every earlier release are affected. Fixed in 7.0.1.
- 6.x line: releases before 6.2.0 are affected. Fixed in 6.2.0.
Both fixes shipped earlier in August. The patch wraps the copy operation in a scope that blocks any user JavaScript, including getters and proxies, from running while the copy happens, which closes the window the attack relied on.
Where a sandbox bug becomes your bug
isolated-vm exists to run code its callers do not trust, so the interesting question is not whether you depend on it directly. It is whether something you run hands attacker-influenced code to a sandbox on your behalf. Endor Labs names n8n, Activepieces, and Mastra AI as projects that use the library, and those tools are exactly the case that matters: they let a workflow author, or an AI step, supply the JavaScript that runs. If a user of your automation platform can write a code node, or if an LLM in the loop can emit one, that is your untrusted input, and this flaw is the path from it to your server.
We have watched this shape before. n8n itself shipped a workflow-editor sandbox escape that let any editor run OS commands, Mastra's npm packages were reported compromised in a supply-chain attack after passing inspection, and Cursor's agent was reported to trust content that could disable its sandbox. The AI automation wave is stacking untrusted-code execution onto self-hosted infrastructure faster than the containment story has matured.
A language isolate is not an operating-system jail
The detail that should change how you build is where the bug lived. It was not in V8's isolate, the part that gets years of adversarial attention from browser vendors. It was in the native C++ code that marshals values across the boundary. A V8 isolate is a strong memory boundary between two pieces of JavaScript, but the glue that copies objects in and out is ordinary code with ordinary bugs, and that glue is attack surface. Patching this advisory closes this instance. It does not retire the class, and you should expect more marshaling bugs in every library that promises to run untrusted code in-process.
The practical consequence: treat a language-level sandbox as a performance and API convenience, not as your containment boundary. The real boundary is the operating system around the process. If an escape is always possible, then the process that hosts the sandbox has to be the thing you actually constrain and watch, the same way you would treat any service that runs code from the internet. Our threat-hunting guidance starts from that assumption.
Upgrade, then put the sandbox inside a real boundary
First, patch. Move the 7.x line to 7.0.1 and the 6.x line to 6.2.0. If you self-host n8n, Activepieces, Mastra, or anything else that bundles isolated-vm, update the platform to a build that ships the fixed library rather than only bumping a direct dependency you may not have.
Then assume the next escape has no patch yet and box the process in. Run the Node.js runtime as a dedicated low-privilege user, drop the capabilities it does not need, keep it off shared secrets, and restrict its outbound network so a compromise cannot phone home or pivot freely. Where the workload allows, put the whole thing in a container or a small virtual machine so an escape lands in an already-limited blast radius, not on the host that runs everything else.
Detection is the part the sandbox cannot do for you, because a sandbox that has been escaped cannot report its own compromise. Baseline what the Node process does in normal operation and alert on deviation: a shell spawned as a child of the runtime, writes outside its working directory, or new outbound connections to destinations it never talks to. That host-level signal is what managed detection watching the host is built to catch, and it is what tells you an escape happened in the window before you patched.