SAN FRANCISCO, 22 AUG 2026 — A flaw in isolated-vm, the Node.js library used to run untrusted JavaScript inside a dedicated V8 isolate, allows code inside the sandbox to corrupt host memory and potentially achieve remote code execution on the host.
It affects all versions up to and including 7.0.0 and is fixed in 6.2.0 and 7.0.1. It is tracked as GHSA-864f-rcv7-6rh4 and, as of publication, carries no CVE identifier.
What broke
The defect is a type confusion in ExternalCopy, the mechanism isolated-vm provides for moving data between the host and the isolate. Type confusion means a value is treated as a different type from the one it actually holds, which allows memory to be read or written outside the bounds the runtime assumed.
The escape therefore happens at the boundary rather than inside it. The isolate itself is not being broken out of by escaping V8; the flaw is in the code that carries data across the wall.
Why isolated-vm existed in the first place
This library matters more than its download count suggests, because of what it replaced.
Node's built-in vm module has never been a security boundary and its documentation says so. The community's answer for years was vm2, which attempted to make untrusted execution safe through interception, and which produced a long sequence of escapes before being abandoned.
isolated-vm took a structurally stronger approach: rather than policing what sandboxed code can reach, it gives that code its own V8 isolate with a separate heap and no shared references. There is no prototype chain to walk back to the host, because there is no shared prototype chain. It was a better design, and it became the community's recommended option.
The finding is important because the isolation model did not fail. The escape came through the interface — the necessary channel for moving data in and out of a sandbox that actually does useful work.
The general lesson is about interfaces, not isolates
Every sandbox faces the same tension. Perfect isolation is trivially achievable and useless; usefulness requires a channel; and the channel is where the bugs live.
This is not a new lesson. Browsers learned it over two decades: V8 itself is strong, but escapes happen at the renderer surface. Hypervisors are usually broken through device emulation, not CPU virtualisation. Containers get escaped through shared kernel interfaces, not failing namespaces.
The pattern is consistent: the simple, heavily-reviewed isolation primitive holds up, but the large, feature-driven marshalling layer on top of it breaks.
When you are selecting a sandbox, do not just ask how strong the isolation is. Ask how wide the interface is, and how much of it you actually need to expose.
Where this is deployed, and why that list has grown
The population at risk has changed shape in the last two years and most of the new entrants are not thinking about it.
Traditionally, `isolated-vm` has been used by platforms that run customer-supplied code — serverless products, workflow builders, rules engines, and so on. Those teams know they are running untrusted code and plan for it.
The newer population is AI infrastructure. Agent frameworks that execute model-generated code, tool-use implementations, plugin runtimes and code-interpreter features all need somewhere to run code that nobody wrote deliberately, and isolated-vm is a common answer in the Node ecosystem.
That matters because model-generated code is untrusted in a way teams sometimes fail to internalise. It is not attacker-supplied in the usual sense, but it is attacker-influenced whenever the model's input is, and prompt injection makes that a routine condition rather than an exotic one. An escape in the sandbox running agent-generated code turns a content-level attack into host compromise.
What to actually do about it
The upgrade is the obvious step and the dependency position makes it less straightforward than it sounds.
Most organisations do not depend on isolated-vm directly. They depend on a platform that does, which means the fix arrives when that platform ships it. Checking your own lockfile is worth five minutes; the answer for many teams will be that the library is present transitively and the version is not theirs to choose.
Two branches exist deliberately. The 6.2.0 release means teams that have not moved to the 7.x line are not being forced to take a major version upgrade to get the fix, which materially raises the chance the patch is actually applied rather than deferred behind a migration.
Beyond patching, the durable control is what the host process can do. A sandbox escape yields the privileges of the process that hosted the sandbox, so a code-execution service running with minimal filesystem access, no ambient cloud credentials and no network egress converts a host compromise into a much smaller event. That is the same lesson the MLflow credential theft this week teaches from the other direction: the vulnerability sets the entry point, the surrounding configuration sets the damage.
No CVE is a practical problem, not a bureaucratic one
The absence of a CVE identifier has consequences that are easy to underestimate.
Most vulnerability management tooling is built around CVE identifiers. They are what scanners match, patch policies reference, SLAs are written against, and compliance reports are built from. An advisory that exists only as a GitHub Security Advisory reaches the subset of teams whose tooling ingests the GitHub advisory database, which is far from all of them.
Node ecosystem tooling generally does consume that database, so npm audit and comparable checks should surface it. Organisations relying on scanners that key strictly on CVE feeds may not see it at all, and will not know they did not see it.
It is worth checking how your own pipeline handles advisories without a CVE, because this problem is not unique to `isolated-vm`.
What remains unconfirmed
No CVE identifier has been assigned as of publication and no CVSS score is available. It is not established whether the flaw has been exploited, whether working exploit code exists publicly, or how difficult exploitation is in practice — type confusion leading to memory corruption is a strong primitive but the path to reliable code execution is not described in the available material.
Who discovered and reported the issue is not stated in the material reviewed, nor is the disclosure timeline before publication, nor whether specific downstream projects have been notified.
What to watch for
The first thing worth watching is CVE assignment. It changes who finds out, and the gap between advisory publication and CVE issuance is itself a measure of how much of the ecosystem is flying blind.
The second is downstream adoption. isolated-vm is a dependency of platforms rather than an application, so the meaningful patch rate is how quickly those platforms ship updated versions, not how quickly the library was fixed.
The third is whether proof-of-concept code appears. Type confusion is a strong primitive, and the difference between theoretical memory corruption and demonstrated host execution determines how urgently the downstream patch cycle moves.
View author profile → · Editorial policy
