A critical flaw in isolated-vm, the Node.js library used to run untrusted JavaScript inside a V8 isolate, lets sandboxed code escape the isolate and achieve remote code execution on the host. The bug is a time-of-check/time-of-use (TOCTOU) weakness in the ExternalCopy path that dereferences an attacker-controlled pointer, and it is fixed in isolated-vm 6.2.0 and 7.0.1. Anywhere isolated-vm is the boundary between untrusted code and your infrastructure, this turns "run it safely in a sandbox" into "run attacker code as the host process."

isolated-vm is widely deployed precisely because it promises isolation: multi-tenant platforms, plugin systems, serverless-style function runners, and, increasingly, tools that execute AI-generated or user-supplied JavaScript all lean on it to contain hostile input. A sandbox escape in that role is worst-case, because the entire threat model assumes the code inside the isolate is untrusted. When the isolation boundary itself is the vulnerability, every input you deliberately treated as dangerous now has a path to the host.

The community discussion around this class of bug keeps returning to one question: can a language-level sandbox ever be a security boundary for genuinely adversarial code? V8 isolates were designed for performance and separation, not to withstand a determined attacker with arbitrary script execution probing native bindings. TOCTOU flaws in the native glue between JavaScript and the host, like this ExternalCopy issue, are exactly the seams where that assumption breaks. For teams building AI agents that run model-generated code, the takeaway is uncomfortable: an in-process JS sandbox is a speed bump, not a wall.

Who is affected by the isolated-vm flaw, and what is the fix?

You are exposed if your application uses isolated-vm to execute code you do not fully trust, whether that is user plugins, tenant-supplied scripts, or AI-generated JavaScript. Update to isolated-vm 6.2.0 or 7.0.1, which close the ExternalCopy path that allowed user JavaScript to trigger the vulnerable dereference. If you only ever run first-party code inside the isolate, the practical risk is far lower, but you should still upgrade.

Is an in-process sandbox enough for untrusted or AI-generated code?

On its own, no. A library sandbox raises the bar but shares the host process and kernel, so a single native-binding flaw collapses it. For genuinely adversarial or model-generated code, layer real isolation underneath: run the untrusted workload in a separate process with least privilege, inside a container or microVM (gVisor, Firecracker) with no ambient credentials, tight egress controls, and resource limits. Defense in depth means the language sandbox is one layer, not the only one.

Our read

The rise of AI coding agents has quietly made "execute this untrusted code" a routine operation, and libraries like isolated-vm are carrying a security burden they were not built to hold alone. This is a supervised-adversary and continuous-verification problem: assume the sandbox will fail, and design so that failure is contained. Test your own agent and plugin runtimes with real escape attempts, put OS-level isolation and credential-free execution around anything that runs generated code, and verify the blast radius of a sandbox escape rather than trusting the library to never break. Verifiable by design means proving the wall holds, not assuming it does.

Reporting by SecurityWeek and The Hacker News; technical details per the isolated-vm project advisory. Sources linked above.

Related: AI coding-agent sandbox escapes in Cursor, Codex and Gemini CLI and GhostSplice malicious MCP servers.