Skip to content
Today
Sections

Build Reports disagree2 publishers 2 min read Published Updated

A double-read in isolated-vm turns customer JavaScript into host code execution

GHSA-864f-rcv7-6rh4 lets guest code hand the C++ bindings one type on the first read and a different one on the second. Fixes are in 7.0.1 and 6.2.0.

The Engineer · Build desk

Send a correction

What happened

  • An advisory tracked as GHSA-864f-rcv7-6rh4 describes isolated JavaScript corrupting the memory of the host Node.js process and taking over its control flow.
  • The trigger is a transferList getter reached through ExternalCopy that returns a normal ArrayBuffer on the first read and an attacker-controlled value on the second.
  • Fixed releases are isolated-vm 7.0.1 and 6.2.0.
  • Products named alongside isolated-vm include n8n, Activepieces and Mastra AI, with workflow or code-execution inputs as the entry point and no end-user action required.

Why it matters

  • Who's exposed exposure The reachable material is no longer the isolate but the worker: host-privilege execution, then the credentials and connection destinations the automation platform holds.
  • What it limits constraint If you cannot ship the upgrade, the offered fallback is to stop handing references into guest code or switch the feature off, which is the bridge those code nodes exist to cross.
  • Who has to decide decision Teams now have to decide whether past reproducible worker segfaults were stability bugs or attempts, because the quiet version of this leaves nothing to grep for.
  • What doesn't add up contradiction The published range and the published patch overlap on the 6.x branch, so a shop pinned at 6.2.x cannot tell from the summary whether it is fixed or affected.

Next story · Build · 1h ago

Cloudflare's Deno deal gives the runtime one more year of monthly fixes

Confirmed2 publishers

A type check that reads a value twice has not checked anything. The bindings validate what the first read returned and then operate on whatever the second read hands back, which is the part the guest controls [3]. Fixing that means either reading once and holding the result, or re-validating at the point of use; a patch that only tightens the check without collapsing the double read leaves the same shape available anywhere else the bindings ask a JavaScript object a question twice.

The entry condition is worth sitting with. The guest needs untrusted execution inside the isolate plus at least one `ivm.Reference` passed in from the host [4]. That reference is the bridge, and the advisory's own fallback for anyone who cannot upgrade is to stop passing references to untrusted code or to turn the feature off entirely [14]. Read those two together and the sandbox stops looking like a wall with a door in it.

The version guidance does not close cleanly. The affected set is given as 7.0.0 or lower, or 6.x below 6.2.0 [18], while the fixed versions are 7.0.1 and 6.2.0 [13]. Taken literally, "7.0.0 or lower" contains 6.2.0, which the same document lists as the remedy [20]. Anyone pinned on the 6.x line cannot resolve their status from that sentence and has to go to the advisory record itself.

Forensics are thin by design. The basic proof of concept ends in `SIGSEGV` and exit 139 [5], with crash sites near `v8::ArrayBuffer::IsDetachable` [6]. The advanced path does not end in a crash; it ends with guest processing in control of the host process [7]. The write-up also notes that the sequence begins inside guest processing with no network signs, and that any outbound traffic afterwards depends entirely on the payload, with nothing published [8]. So the loud artifact belongs to the attempt that failed, and the quiet one is the case you care about.

On the strength of the evidence: the record reports no observed exploitation in public information, and only proof-of-concept-style `transferList` and getter inputs confirmed internally [15]. It also carries a severity of high [19] while the Endor Labs write-up it points to, dated 20 August 2026, is titled as critical [9], and lists the GHSA identifier with no CVE attached [10]. Investigation guidance names audits of code execution nodes and workers in tools like n8n, worker environment variables, cloud credentials and connection destinations [16]. That is where the value sits, and it always did. What changed is the confidence you can place in the isolate that was drawn between it and the customer's expression field [1].

What to watch

  • Whether a CVE is assigned, and whether n8n, Activepieces or Mastra AI state which isolated-vm version their shipped releases bundle.
  • The first credible report of exploitation beyond a proof of concept, which moves this from crash triage to token rotation.
  • Whether the fix removes the second read or only re-validates it, since a re-check leaves the same pattern available elsewhere in the bindings.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence60
Adoption50
Hype gap+20
Incentives60
Confidence58
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Advisory GHSA-864f-rcv7-6rh4 describes a type confusion in isolated-vm in which isolated JavaScript exploits a double-read difference in values to corrupt the memory of the host Node.js process and take over its control flow.

    Reported Supported Source: Endor Labs advisory write-up as summarised on dev.toView cited source
  2. [2]

    The guest reaches the ExternalCopy constructor, and the getter of transferList returns a normal ArrayBuffer on the first read and another attacker-controlled value on the second read.

    Reported SupportedView cited source
  3. [3]

    The C++ bindings trust the type check from the first read and treat the value as an ArrayBuffer without re-checking the second read, leading to reading and writing control addresses and hijacking host control flow.

    Reported SupportedView cited source
  4. [4]

    Preconditions are that the host runs untrusted JavaScript inside isolated-vm and passes at least one ivm.Reference, and that the guest can reach ivm.Reference or an attacker-controlled transferList.

    Reported SupportedView cited source
  5. [5]

    In a basic proof of concept the Node.js host crashes abnormally with SIGSEGV / exit 139.

    Reported SupportedView cited source
  6. [6]

    Crashes occur near v8::ArrayBuffer::IsDetachable.

    Reported SupportedView cited source
  7. [7]

    In an advanced exploit, normal guest processing moves to host process control, so the outcome does not end with just a crash.

    Reported SupportedView cited source
  8. [8]

    Exploitation usually starts with internal guest processing and shows no network signs; outbound traffic after exploitation depends on the payload, and no public information is available.

    Reported SupportedView cited source
  9. [9]

    The referenced source is an Endor Labs article dated 20 August 2026 titled "GHSA-864f-rcv7-6rh4: Critical Type Confusion Vulnerability in isolated-vm".

    Reported SupportedView cited source
  10. [10]

    The record lists advisory GHSA-864f-rcv7-6rh4 and no CVE identifier.

    Reported SupportedView cited source
  11. [11]

    Related products listed are isolated-vm, Node.js, V8, n8n, Activepieces and Mastra AI, and no end-user action is required because inputs to AI workflows or code execution features can be the entry point.

    Reported SupportedView cited source
  12. [12]

    Stated impact includes crash of the host Node.js process, destruction of the guest/host boundary, potential arbitrary code execution with host privileges, and spread to credentials and connection destinations of AI and automation platforms.

    Reported SupportedView cited source
  13. [13]

    The remediation is updating to isolated-vm 7.0.1 or 6.2.0.

    Reported SupportedView cited source
  14. [14]

    Listed mitigations besides upgrading include not passing references to untrusted code or stopping the feature, running code execution workers with low privileges as disposable instances with network isolation, and monitoring crashes and abnormal memory access.

    Reported SupportedView cited source
  15. [15]

    No actual exploitation has been observed in public information; only proof-of-concept-like transferList and getter inputs are confirmed within the organization.

    Reported SupportedView cited source
  16. [16]

    Recommended investigation covers audits of code execution nodes and workers in tools like n8n, JavaScript and execution history generated or received by AI agents, worker environment variables, cloud credentials and connection destinations, and rotating tokens if compromise is suspected.

    Reported SupportedView cited source
  17. [17]

    The only low-cost detection signal belongs to the unsuccessful case: the basic proof of concept segfaults, while the advanced path produces no crash and no network signature, so an absence of worker crashes is not evidence that exploitation did not occur.

    Derived Supported
  18. [18]

    Affected configurations are described as using isolated-vm version 7.0.0 or lower, or version 6.x below 6.2.0.

    Reported ContestedView cited source
  19. [19]

    The record lists the severity as high.

    Reported ContestedView cited source
  20. [20]

    The affected range as written contradicts the patch list on the 6.x branch: 6.2.0 is lower than 7.0.0 and therefore falls inside "7.0.0 or lower", while the same document names 6.2.0 as a fixed version.

    Derived Contested

Sources

2 independent publishers whose own reporting we read for this story.

  1. dev.to

    1 article · August 21, 2026

    JavaScript Sandbox Escape via Type Confusion in isolated-vm

  2. endorlabs.com

    1 article · August 22, 2026

    We discovered a critical vulnerability in isolated-vm a sandbox that is widely used in popular AI-related projects | Blog | Endor Labs

Topics and entities

Topics

  • AI agent code execution security
  • JavaScript sandboxing

Entities