Critical isolated-vm bug enables sandbox escape into Node.js hosts
Researchers have disclosed a critical vulnerability in isolated-vm, the Node.js library used to run untrusted JavaScript in separate V8 Isolates. The issue, tracked as GHSA-864f-rcv7-6rh4, affects all releases through version 7.0.0. Maintainers have issued fixes in versions 6.2.0 and 7.0.1.
Endor Labs found that a sandboxed guest could exploit the flaw to corrupt memory in the host process. The demonstrated impact ranges from a reliable controlled-address crash, resulting in denial of service, to host-process control-flow hijacking that could enable remote code execution.
A flaw in data transfer between isolates
isolated-vm creates separate V8 Isolates so multiple JavaScript environments can run concurrently without sharing state or heaps. Objects cannot be passed directly from the main Node.js thread to a worker isolate. Instead, the library's ExternalCopy class serializes values out of the host isolate and deserializes them in the guest environment.
The defect lies in ExternalCopy's processing of the transferList option. Endor Labs researcher Cristian-Alexandru Staicu described it as a type-confusion vulnerability that permits code inside a sandbox to corrupt memory in the host application. Starting with a single ivm.Reference, the usual mechanism through which a host grants a guest a capability, the research team escalated a controlled-address crash into a guest-to-host sandbox escape.
The issue is significant because isolated-vm is a widely used open-source package, with more than 2,900 GitHub stars and nearly one million npm downloads in the preceding week. The finding also fits the developer-security risks tracked in npm supply-chain activity and exploit chains, where npm supply-chain activity and exploit chains remain operational concerns for software teams.
V8 isolation held, but the binding layer did not
Staicu stressed that the underlying V8 Isolate primitive was not broken. The boundary between isolates held; the failure was in the C++ glue code responsible for marshaling values across that boundary. This distinction matters for teams that treat a sandbox as a complete security boundary: surrounding bindings and capability-passing mechanisms require the same scrutiny as the underlying runtime primitive.
Project maintainer Marcel Laverdet said any guest given an ivm.Reference could trigger the minimum demonstrated denial-of-service condition. At the upper end, host control-flow hijacking represents potential remote code execution. Detailed exploit information has been withheld to reduce the risk of misuse.
What development teams should do
Organizations using isolated-vm should identify installed versions in development and deployment environments and move to a patched release. They should also review where untrusted JavaScript is executed and which capabilities are exposed through ivm.Reference. The practical business implication is clear: updating isolated-vm to 6.2.0 or 7.0.1 and minimizing guest capabilities reduces exposure to a flaw that can turn sandboxed code into a host-process risk.