# The Sandbox Was the Hole: How isolated-vm Turned V8's Security Primitive Against Itself
The whole point of isolated-vm is that untrusted code stays contained. Run someone else's JavaScript, let it do its thing, wall it off from your host process. That's the contract. A type confusion bug disclosed this week broke that contract completely — a crafted payload from inside the sandbox could hijack control flow on the host and achieve full remote code execution.
This isn't a vulnerability in some obscure corner of the stack. isolated-vm is how thousands of Node.js platforms let users execute arbitrary JavaScript. It's the engine under online coding environments, AI-powered code runners, SaaS plugin systems, and multi-tenant serverless platforms. If you're running untrusted JavaScript and you're not inside a full container or VM, there's a reasonable chance isolated-vm is the thing standing between your users and your infrastructure. Or rather, it was.
## What the Bug Actually Does
The vulnerability lives in ExternalCopy, the mechanism isolated-vm uses to shuttle data between Isolates — the separate V8 instances that are supposed to be fully walled off from each other. When moving large ArrayBuffers, the code does something sensible for performance: instead of copying the underlying memory byte-for-byte, it *transfers* it, detaching the buffer from the source Isolate and handing it to the destination.
The problem is a classic time-of-check/time-of-use flaw buried in the C++ binding layer. The native glue code walked the transferList JavaScript array twice — once to check it, once to act on it. Between those two passes, an attacker-controlled JavaScript getter could return a completely different value. The second pass trusted the first walk implicitly. It didn't.
That misplaced trust let an attacker dereference an attacker-controlled pointer. From there, the outcomes are a V8 sandbox escape and control-flow hijack of the host process — which, in practice, means arbitrary code execution on the machine running your Node.js application.
The attack surface is wider than it sounds. The ExternalCopy constructor is host-only, but an attacker operating from inside the guest Isolate doesn't need to call it directly. They can target ivm.Reference — the mechanism hosts use to expose objects into the sandbox — to construct a malicious transferList and trigger the same code path. In the project's own advisory language: "Any embedder that runs untrusted code in an isolate and shares even one Reference into it is affected."
That qualifier is doing a lot of work. Sharing a Reference into an Isolate is not an edge-case configuration — it's standard practice. It's how you give guest code access to anything useful.
## A Bug in the Glue, Not the Glass
EndorLabs, which identified the flaw, put it precisely: the vulnerability lived in the native glue code — the C++ binding layer that serializes values across the Isolate boundary. That layer manipulates raw V8 handles and backing-store pointers. It's not managed memory. It's not JavaScript's type system protecting you. It's C++, and a single unchecked cast on a re-read value was enough to turn an isolation primitive into an escape hatch.
This distinction matters for how defenders think about risk. The JavaScript sandbox was working correctly. V8's Isolate model was working correctly. The failure happened at the seam — the translation layer written in a language that doesn't hold your hand, performing a security-critical operation while trusting attacker-influenced data halfway through.
Patches are available in isolated-vm versions 6.2.0 and 7.0.1. The fix prevents user JavaScript from executing during the copy operation, closing the window for a getter-based race. No CVE identifier has been assigned yet as of this writing.
## Who's Actually Exposed Right Now
Think about where isolated-vm shows up in the real world:
Every one of these use cases involves exactly the threat model isolated-vm was built to address: untrusted JavaScript, running on infrastructure you own, where containment is the entire security guarantee.
The blast radius depends on what's reachable from the host process. In a cloud environment, that could mean access to credentials, internal APIs, adjacent services, or customer data. The vulnerability requires the ability to execute code inside an Isolate — which, for most of these platforms, is precisely the capability users are given by design.
---
## HackWire Analysis
The isolated-vm disclosure belongs to a pattern that keeps recurring and keeps being underestimated: security infrastructure as attack surface.
The instinct when you have untrusted code is to reach for a sandboxing library. That's the right instinct. But sandboxing libraries are complex, they interface with low-level runtime internals, and they're disproportionately written in memory-unsafe languages for performance reasons. When the sandbox itself has a bug, the attacker's position is ideal — they have code execution *inside* the security boundary and just need to find the seam.
Compare this to the VM escape bugs that have appeared in hypervisors over the years, or the container breakouts in runc and libcontainer. The mechanism is different, but the logic is the same: the abstraction that's supposed to contain the attacker becomes the pivot point. V8 Isolates are not containers. Isolated-vm's documentation has always said so. But in practice, many platforms treat the isolation guarantee as equivalent to a container boundary — and their threat models are built accordingly.
What's missing from most coverage of this vulnerability is a frank assessment of detection difficulty. A successful sandbox escape leaves no crash — control flow is hijacked silently. If your monitoring is looking for exceptions, panics, or abnormal process termination, a clean exploitation will likely walk right past it. Defenders need to think about host-process behavioral monitoring: unusual child processes, unexpected network connections originating from the Node.js runtime, file system access outside expected paths.
The timing is also notable. Code execution environments powered by LLMs are proliferating rapidly, and many of them use isolated-vm or similar primitives to safely run AI-generated code. The sandboxing layer is being trusted with a new category of attacker input — not just human-written submissions, but machine-generated code that could be intentionally crafted to exploit exactly these seams.
Upgrade immediately. Audit every place a Reference is shared into an Isolate and treat those surfaces as externally influenced.
— HackWire Editorial
---
## Related Coverage