# The Glue Code That Breaks the Cage: Inside the isolated-vm Sandbox Escape
There's a particular kind of security failure that reveals something uncomfortable about how software is actually built. Not a cryptographic blunder, not a logic error in business rules — but a bug in the invisible seams between layers. The kind of bug that proves your sandbox was never as solid as you thought, even when the sandbox itself worked fine.
That's exactly what happened with isolated-vm.
## What isolated-vm Actually Does — and Why It's Everywhere
If you've built anything that executes user-supplied JavaScript on the server side — a plugin system, a code execution sandbox, a multi-tenant scripting environment — there's a reasonable chance you've reached for isolated-vm. The Node.js library sits atop Google's V8 engine and spins up independent JavaScript environments called Isolates: separate heaps, separate state, no shared data. Each one is supposed to be its own sealed box.
The package pulls nearly a million npm downloads a week. It's in production environments where the threat model explicitly includes adversarial code.
That detail matters. This isn't a library for running code you wrote. It's a library for running code you didn't write, from people you might not trust.
## The Bug Is in the Bridge, Not the Box
Researchers at Endor Labs disclosed a critical flaw this week — identifier GHSA-864f-rcv7-6rh4, no CVE assigned yet — affecting all versions of isolated-vm through 7.0.0. Patches landed earlier this month in 6.2.0 and 7.0.1.
The vulnerability lives in ExternalCopy, the mechanism isolated-vm uses to move JavaScript objects between the host and the sandbox. Because V8 Isolates can't share memory directly, there needs to be a serialization and deserialization layer. ExternalCopy is that layer.
And it's where things go wrong.
Endor Labs researcher Cristian-Alexandru Staicu found a type confusion in how ExternalCopy handles the transferList option. That's the parameter that tells the library which objects to transfer rather than copy. The confusion at the C++ binding layer between what the guest isolate hands over and what the host process expects to receive turns into something much worse than a data type mismatch — it turns into a memory corruption primitive.
From there, the exploit chain Staicu documented reads like a precision instrument being assembled from scratch. Starting with only an ivm.Reference — the standard token a host passes to a sandbox to give it any capability at all — he escalated from a controlled-address crash to full control-flow hijack of the host process. The minimum impact: a reliable denial-of-service, triggerable by anything with a reference. The maximum: remote code execution in the host application.
Project maintainer Marcel Laverdet confirmed both in the advisory. Full exploit details are being withheld while the patching window stays open.
## V8 Held. The Wrapper Didn't.
Here's the line from Staicu that deserves to be read twice: "What was not broken was the isolation primitive itself. V8's Isolate boundary held. What failed was the C++ glue code that marshals values across that boundary."
This is a crucial distinction, and it's one that gets lost in the coverage. People hear "sandbox escape" and assume the entire foundation is rotten. It isn't. The isolation model is sound. What failed was the handwritten C++ that connects V8 to Node.js — the binding layer that translates between the JavaScript world and the host process.
That binding layer doesn't get the same scrutiny as the cryptographic primitives or the isolation logic. It's infrastructure code. It's assumed correct. It handles edge cases in the type system that nobody thinks about until someone like Staicu starts pulling on threads.
## HackWire Analysis
The isolated-vm vulnerability fits a pattern that keeps surfacing in sandboxing infrastructure: the attack surface isn't the sandbox, it's the protocol for crossing in and out of it.
Consider the parallel to browser-based sandbox escapes. When Chromium's renderer process gets exploited, it's almost never V8's fault — it's the IPC layer, the codec, the image decoder. The security community has internalized this for browsers over fifteen years of CVEs and zero-click chains. The server-side JavaScript sandbox ecosystem is only now encountering the same lesson.
What makes this particularly sharp right now is the deployment context. isolated-vm is heavily used in AI-adjacent infrastructure — think code execution sandboxes for LLM tool use, plugin runtimes for AI coding assistants, and multi-tenant environments where users paste arbitrary scripts into interfaces and expect them to run safely. That's not speculation; it's visible in the repository's issue tracker and the organizations citing it.
If you're running user-provided code to power an agent's "code interpreter" capability, you probably trusted isolated-vm to be the security boundary. For versions through 7.0.0, any user who received an ivm.Reference — which is the default way to give a sandbox anything useful — could crash your host process at minimum, or do considerably worse.
The fix exists. But the organizational problem is that libraries like this tend to get pinned and forgotten. They're dependencies of dependencies. The team that chose isolated-vm two years ago may not be the team maintaining the service today. Patch communication across transitive dependency chains is still a solved-in-theory, broken-in-practice problem.
Defenders running Node.js applications that execute untrusted code should audit their dependency tree now. npm ls isolated-vm is the first command. If you're below 6.2.0 or between 7.0.0 and 7.0.1, you're exposed. And if you're on a fork or a vendored copy that hasn't been updated, the patch timeline is entirely yours to own.
The deeper lesson for architects: binding layers deserve adversarial review. The primitives get audited. The glue rarely does.
— HackWire Editorial
## Related Coverage