The sandbox teams fled vm2 for now has its own guest-to-host escape

Endor Labs has disclosed a critical flaw in isolated-vm, the Node.js sandbox most teams moved to after vm2's repeated failures, that lets code running inside the sandbox corrupt memory in the host process ^[1]. The maintainer has shipped fixes in versions 7.0.1 and 6.2.0 ^[2], which means "we run untrusted code in isolated-vm" is no longer an architecture answer; it is a version answer.

The distinction matters because isolated-vm earned its reputation honestly. vm2 built a security boundary inside a single V8 execution environment using proxies and prototype scrubbing, with untrusted code sharing some of the same elements ^[3], and over the years there were some two dozen instances of code breaking out, including one Endor Labs documented earlier this year ^[4]. isolated-vm instead gives each sandbox its own V8 Isolate, an independent instance of the engine with separate built-ins and no shared object graph with the host ^[5]. Cris Staicu, senior security researcher at Endor Labs, calls that the same primitive Chrome uses to separate tabs, with guest code getting no require, no host globals and no references to host objects unless the embedder explicitly hands them over ^[6].

That boundary is not what broke. According to Staicu, the researchers did not break the V8 Isolate sandbox, they broke the code that carries data into it ^[7]. The bug is a type confusion in how ExternalCopy handles the transferList option ^[8]. ExternalCopy serializes data out of one isolate heap and deserializes it into another; when a transferList is present, the constructor iterates the list twice, validating and registering every element on the first pass and transferring each element on the second without revalidating ^[9]. That is a time-of-check-to-time-of-use gap, where state checked in the first step is assumed unchanged when used moments later ^[10]. Staicu wrote that the attacker registers a stateful getter that hands a genuine ArrayBuffer to the validating walk and something else to the unchecked walk ^[11].

Reachability is the part worth reading twice. transferList is accepted only by the ExternalCopy constructor, which appears to be accessible only on the host side ^[12], but the guest does not need the whole ivm module, only a single ivm.Reference, the ordinary mechanism a host uses to hand a sandbox any capability at all ^[13]. From that starting point, Endor Labs escalated the bug from a controlled-address crash to hijacking the host's control flow, which it describes as a full guest-to-host sandbox escape ^[14]. The low end of that is a guest-triggered crash and denial of service; the high end is remote code execution outside the sandbox, in the host ^[15].

Scale is why this is an operations problem rather than a reading item: isolated-vm is used by more than a million projects and sees more than a million downloads a week, including AI and automation platforms ^[16]. The issue is tracked by Endor Labs as GHSA-864f-rcv7-6rh4, with a CVE assignment pending ^[17]. Fixes landing as both 7.0.1 and 6.2.0 means two release lines have patched builds, so sitting on the older major is not a reason to defer ^[18].

Watch for the CVE assignment attaching to the GHSA identifier ^[17], and check whether isolated-vm enters your tree transitively through an AI or automation dependency rather than directly ^[16]. Then do the audit Endor Labs actually asks for, which is scrutinising how your sandboxes could cross security boundaries ^[19] - starting with how many ivm.Reference handles you pass across, given that one is sufficient ^[13].