August 29, 2026: One ordinary object reference is enough for sandboxed JavaScript to reach a memory-corruption flaw in the host process running isolated-vm. Researchers demonstrated a controlled-address crash and then host control-flow hijacking, breaking the boundary the Node.js package is meant to enforce.
The flaw was disclosed on August 8, and broader coverage followed on August 20. It remains newly actionable for teams inventorying automation and AI code runners because the two maintained branches require different first-fixed releases: isolated-vm 6.2.0 and 7.0.1. The sources report no active exploitation and do not quantify vulnerable deployments.
Two reads split the type
The defect sits in ExternalCopy, the isolated-vm class that serializes values across a V8 Isolate boundary. Its transferList option moves an ArrayBuffer without copying its backing memory. The maintainer advisory shows that ExternalCopySerialized walks this list twice.
The first walk calls IsArrayBuffer() on every element and rejects a different type. The second walk reads every element again, casts it with As<ArrayBuffer>(), and passes it into ExternalCopyArrayBuffer::Transfer. That second cast has no new type check.
Each read goes through JavaScript’s property access machinery. A stateful getter can therefore return a real ArrayBuffer during validation and a different value during transfer. The proof of concept returns the integer 0x41414141 on the second read. The host then dereferences the confused value while calling IsDetachable() and GetBackingStore().
The resulting fault occurs at 0x4141414100000047, an address derived from the supplied integer. The advisory describes that controlled-address crash as the minimum demonstrated impact. The researchers also used attacker-controlled memory in the destruction path to reach an indirect call through a forged vtable, producing a host control-flow-hijack primitive.
Figure details
A guest isolate holds one host-provided ivm.Reference and obtains the ExternalCopy constructor. A transferList getter returns a genuine ArrayBuffer during the first walk, so validation succeeds. The same getter returns an attacker-selected value during the second walk. Because the second walk casts without another type check, ExternalCopyArrayBuffer::Transfer dereferences the confused value in the host process. The demonstrated outcomes progress from a controlled-address crash to host control-flow hijacking.
One reference reaches the host
The vulnerable constructor initially appears to be a host-side API. Guest code reaches it through the ordinary capability bridge that isolated-vm provides. A guest holding one ivm.Reference can call ref.getSync('x', { externalCopy: true }).constructor, obtain the live ExternalCopy class, and create the malicious transferList from inside the isolate.
That condition narrows the demonstrated scope without making it exotic. References are the standard mechanism for giving a sandbox access to any host capability. Endor Labs, the security vendor that found the flaw, names workflow automation, low-code, edge-compute, chat, and AI-agent projects that use isolated-vm. The report establishes breadth through named examples, but it does not establish how many deployments run an affected version or expose a Reference to untrusted code.
Direct host-side use has a separate reachability condition. Host code is affected when it accepts a caller-influenced array as transferList, even without guest execution. For the sandbox path, the sources demonstrate capability from a single Reference; they do not claim that guest code with no Reference can trigger the flaw.
Fixed branches restore the boundary
The countervailing finding is architectural. The V8 Isolate kept its separate heap and object graph. The failure occurred in the C++ code that marshals values across that boundary. Endor Labs summarizes it plainly: “We did not break the V8 Isolate. We broke the code that carries data into it.”
The isolated-vm maintainer published the advisory and fixes. Teams staying on the 6.x line should upgrade to at least 6.2.0. Teams on 7.x should upgrade to at least 7.0.1. Older branches should move to a maintained fixed line rather than treating process isolation alone as remediation for the vulnerable binding.
Temporary reduction of guest capabilities can shrink the demonstrated attack surface, especially where a runner can operate without any ivm.Reference. It does not repair a caller-influenced transferList in host code, and it is a poor substitute where a Reference is required for the sandbox to do useful work. The package upgrade removes the confused second read at the boundary itself.
Inventory every sandboxed runner
Begin with dependency inventory in each Node.js service, worker image, and build context that executes user- or model-generated JavaScript. Run npm ls isolated-vm --all and retain the resolved tree with the image or deployment identifier. Search lockfiles and vendored application bundles too, because a top-level manifest can omit a transitive or packaged copy.
Then identify which runners pass an ivm.Reference into untrusted code or construct ExternalCopy with caller-influenced transfer lists. Those call sites match the two demonstrated reachability conditions. Prioritize internet-facing automation, multi-tenant code execution, and agent platforms where guests are expected to handle adversarial input.
The verification test is a fresh npm ls isolated-vm --all result from every deployed build context after rebuilding and rollout. The expected result is that each supported 6.x finding resolves to 6.2.0 or later, each 7.x finding resolves to 7.0.1 or later, older branches are absent, and the deployed image digest matches the inspected build.
Sandbox strength depends on every layer that carries data across its boundary. A sound isolation primitive cannot compensate for unsafe native marshaling around it. Patch the binding, verify the deployed dependency tree, and treat exposed Reference paths as part of the security boundary during future design review.