On 19 August 2026, researchers at Endor Labs disclosed GHSA-864f-rcv7-6rh4, a critical vulnerability in isolated-vm — the Node.js library that a large portion of the AI agent and workflow automation ecosystem uses to execute untrusted code safely.
The technical summary is short. isolated-vm creates genuinely separate V8 isolates, each with its own heap, and moves values across the boundary through a serialisation layer called ExternalCopy. That layer is implemented in C++ glue code. A type confusion in ExternalCopy’s handling of the transferList option lets JavaScript running inside the sandbox corrupt memory in the host process. Corrupted host memory means potential control-flow hijack, and control-flow hijack means potential remote code execution on the host.
Every version through and including 7.0.0 is affected. Fixes shipped in 6.2.0 and 7.0.1. The package sees more than a million downloads a week. Named downstream projects include n8n, Mastra, Sim.ai and Activepieces — automation and agentic AI platforms whose core function is running code that a model, or a user, generated.
This site covered the Langflow CVE-2026-9198 KEV entry in early August and Ray CVE-2025-62593 on 17 August. This is the third AI-infrastructure vulnerability in three weeks with the same shape. That is no longer a coincidence; it is a pattern with governance implications.
Why this one is structurally worse
Most vulnerabilities break a control that sits alongside other controls. This one breaks a control that, in a great many deployments, is the whole control set.
Consider how an agentic platform typically justifies executing model-generated code. The security narrative, whether written down or not, runs:
- The model may generate arbitrary code, including malicious code.
- We do not attempt to determine whether generated code is safe, because that determination is undecidable.
- Instead we execute it in a sandbox that cannot reach the host, the network, the filesystem, or other tenants’ data.
- Therefore arbitrary generated code is acceptable.
Steps 1 and 2 are honest and correct. Step 4 depends entirely on step 3 being true. GHSA-864f-rcv7-6rh4 makes step 3 false, and when step 3 is false, nothing else in the chain catches the failure — because the design deliberately removed everything else.
This is what distinguishes a sandbox escape from an ordinary RCE. An ordinary RCE requires an attacker to reach a vulnerable endpoint. A sandbox escape in an agent platform is reachable by design: the platform’s entire purpose is to accept and run attacker-influenceable code. There is no exploitation precondition to argue about. The precondition is the product.
The prompt injection chain
The exposure widens once you consider how code reaches the sandbox in an agentic system.
In a conventional automation platform, sandboxed code is written by an authenticated user configuring a workflow. The trust model is “authenticated user can run code in a sandbox” — bad, but bounded by authentication.
In an agentic system, sandboxed code is frequently written by a model in response to content the model retrieved. A support agent that reads a ticket, a research agent that fetches a web page, a document-processing agent that parses an uploaded PDF — each of these takes untrusted external content into a context window, and each may then emit code into the sandbox.
That produces a full chain:
Untrusted external content → prompt injection → model emits crafted JavaScript → sandbox executes it → type confusion → host memory corruption → RCE on the host.
Every link in that chain is a documented, reproducible technique. The final link was the one everybody assumed was solid.
And the host, in these architectures, is rarely a bare machine. It is typically a process holding the platform’s own service credentials — the API keys, database connections, OAuth tokens and cloud IAM roles the agent needs to do useful work. This is precisely the credential blast radius problem that made Langflow a KEV entry: the compromise does not stop at code execution, it continues into whatever the compromised process is authorised to reach.
What frameworks actually require here
There is a tendency to treat AI agent security as unregulated territory. It is not. Several existing frameworks impose obligations that this vulnerability directly implicates — the obligations simply were not written with agents in mind.
ISO/IEC 42001
A.6.2.4 (AI system verification and validation) and A.6.2.6 (AI system operation and monitoring) require an organisation to verify that an AI system operates as intended and to monitor it in operation. An AI management system that documents “untrusted code is executed in an isolated sandbox” as a control has made a verifiable assertion. Verification means testing that the isolation holds — not reading the library’s README.
A.5.2 (AI risk assessment) requires assessment of risks arising from the AI system throughout its lifecycle. A risk assessment that treats the sandbox as an assumption rather than as a component with its own vulnerability history is incomplete.
SOC 2
Under the Trust Services Criteria, the relevant provisions are CC6.1 (logical access controls restricting access to protected information assets), CC6.6 (measures to protect against threats from sources outside system boundaries), and CC7.1 (detection and monitoring of configuration changes and vulnerabilities).
If your system description tells auditors and customers that customer-supplied or model-generated code runs in isolation, that statement is now materially affected by a known critical vulnerability. A service organisation that continues to run an affected version after the fix is available, while describing the sandbox as an operating control, has an exception waiting to be written. Whether it becomes a qualified opinion depends on remediation timeliness and on whether the description was accurate during the period.
PCI DSS 4.0
For any agent platform touching cardholder data environments, Requirement 6.3.3 requires that all system components be protected from known vulnerabilities by installing applicable security patches, with critical or high-security patches installed within one month of release. The fixes landed earlier in August. That clock is running.
Requirement 6.2.4 — addressing common software attacks in bespoke and custom software, including injection attacks and improper handling of untrusted input — reads uncomfortably well against an agent architecture whose central design assumption is that untrusted input can be safely handled by a single library.
EU AI Act
Article 15 requires that high-risk AI systems be designed and developed to achieve an appropriate level of accuracy, robustness and cybersecurity, and specifically that they be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.
Article 15(5) explicitly contemplates measures against data poisoning, model poisoning, adversarial examples and confidentiality attacks. Prompt injection into a code-executing agent is squarely within the class of attacks contemplated. A high-risk deployer relying on a single defeated isolation boundary has an Article 15 gap, not merely a patching gap.
NIS2 and DORA
For essential and important entities under NIS2 Article 21(2)(e) — security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure — and for financial entities under DORA Articles 8 and 9, the obligation is to identify ICT-supported business functions and the ICT assets supporting them, and to maintain protection.
The practical question both raise: is your agent platform in your asset inventory, and is isolated-vm in your SBOM? For a large number of organisations the honest answer to both is no, because the platform was adopted by a business team as a SaaS-like automation tool and never went through architecture review.
Immediate response
Determine exposure, transitively. Direct dependency on isolated-vm is the easy case. The harder case is transitive: you may be running it inside n8n, Mastra, Sim.ai, Activepieces, or a vendor product that embeds one of those. Run npm ls isolated-vm across your Node estate, query your SBOM inventory, and — critically — ask your SaaS vendors directly. A vendor security questionnaire that asks “do you use isolated-vm, and at what version” is a reasonable and specific question to send this week.
Patch to 6.2.0 or 7.0.1. This is not a configuration mitigation. There is no transferList setting that makes the type confusion safe. Upgrade.
Where you cannot patch immediately, add the boundary that should have existed anyway. Run the sandbox process in a container or microVM with no ambient credentials, no cloud instance metadata access, egress-filtered networking, a read-only root filesystem, dropped capabilities, and a seccomp profile. A host RCE inside that envelope is a contained incident. A host RCE in a process holding your production database credentials is not.
Rotate credentials reachable from the sandbox host. If you ran an affected version in production with reachable untrusted input, treat host-held secrets as potentially exposed. This is the same discipline the Langflow incident required and the same one most organisations skipped.
Check your logs for what you cannot see. Sandbox escapes are hard to detect after the fact because the sandbox is, by design, not instrumented like the host. Look for anomalous process spawns from the Node host, unexpected outbound connections from sandbox-hosting workloads, and credential use from unexpected source addresses in the period the affected version was running.
The governance change this should force
Patching is the easy half. The harder half is that this vulnerability invalidates a design pattern that a great many organisations adopted without recording that they had adopted it.
Stop treating “sandboxed” as a control statement. It is a control category. A control statement names the mechanism, its version, its threat model, its known limitations, and how it is verified. “Untrusted code runs in isolated-vm 7.0.1, which provides V8 isolate separation but shares the host process address space and has a history of memory-safety defects in its serialisation layer; compensating containment is provided by [X]” is a control statement. “Sandboxed” is a hope.
Require defence in depth for any code-executing agent. The single-boundary architecture is not defensible for a system that executes attacker-influenceable input by design. Minimum: process isolation plus container/microVM isolation plus credential isolation plus egress control. Each layer should be independently sufficient to prevent catastrophic loss.
Put agent platforms through architecture review. The reason so many organisations will struggle to answer the exposure question this week is that n8n, Activepieces and similar tools are frequently adopted as productivity software rather than as code-execution infrastructure. They are code-execution infrastructure. Classify them accordingly in your asset inventory, your SBOM programme, and your vendor risk tiering.
Treat memory-unsafe boundary code as a risk register entry. The defect here is in C++ glue serialising values across a trust boundary. That description fits a large number of sandboxing, parsing and IPC libraries. Where your security model depends on a boundary implemented in a memory-unsafe language, that dependency belongs in the risk register with a named owner — not buried in a transitive dependency tree.
The wider point
Three AI-infrastructure vulnerabilities in three weeks — Langflow, Ray, and now isolated-vm — share a common cause. The AI tooling ecosystem was built quickly, by teams optimising for capability, in a period when nobody was asking these packages compliance questions. That grace period is over, and the frameworks that now apply were not relaxed to accommodate it.
The organisations that will handle this well are the ones that already know where their agent platforms run, what credentials those platforms hold, and what the containment boundary actually is. The ones that will handle it badly are the ones discovering this week that “the sandbox handles it” was written down nowhere, verified by no one, and relied upon by everything.
This article is provided for informational purposes only and does not constitute legal advice.
