Langflow CISA KEV listing proves AI agents do not belong on the internet

CISA added Langflow CVE-2026-55255 to its Known Exploited Vulnerabilities catalogue on 7 July 2026, making it the first AI agent framework on the US federal must-patch list. Sysdig observed the flaw being exploited in the wild on 25 June, with an initial probe some three days earlier. The lesson is architectural. Shared-tenant orchestrators reachable from the public internet fail. Agent runtimes belong on customer-owned hardware, per tenant, with no egress.

What CISA published on 7 July 2026

On 7 July 2026 the US Cybersecurity and Infrastructure Security Agency added CVE-2026-55255 to its Known Exploited Vulnerabilities catalogue with a federal patch deadline of 10 July. The listing was significant for one reason. It was the first entry on the KEV list for an AI agent framework. Every previous KEV entry had been an operating system, an application server, a browser, a network device or a productivity suite. The KEV catalogue is not a threat feed. Entries appear only when CISA has evidence of active exploitation. For Langflow that evidence came from Sysdig's Threat Research Team, which had watched an operator run a methodical intrusion session against exposed Langflow instances between 22 and 25 June 2026, replaying stolen flow identifiers with the plain-text instruction to leak API keys.

The vulnerability, plainly stated

CVE-2026-55255 is an Insecure Direct Object Reference in Langflow's /api/v1/responses endpoint, inside the get_flow_by_id_or_endpoint_name helper. Any authenticated user, including a low-privilege one, could execute another user's saved flow by supplying the target flow identifier. Because Langflow flows carry embedded configuration, the hijacked flow leaked whatever it was configured with. In the observed intrusions that meant OpenAI keys, Anthropic keys, LLM provider credentials, cloud secrets and the prompts sitting inside the flow. The bug was scored 9.9 on CVSS 3.1. It affected every Langflow build prior to 1.9.1. That is the honest description. It is not exotic. It is a missing ownership check on a public endpoint, in a piece of software the industry had adopted as its default AI agent orchestrator.

Why shared-tenant orchestrators are the wrong shape

The architectural pattern under attack is not Langflow specifically. It is the pattern Langflow sits on. A single hosted control plane, holding every customer's agent definitions, every customer's API keys, every customer's tool bindings and every customer's model routing rules, behind an authentication layer. When that layer has a hole, the blast radius is every tenant simultaneously. This is the shape that took down every shared-tenant SaaS the KEV catalogue has ever listed. The AI agent version is worse in three specific ways. First, the object being multiplexed is a chain of tool calls with real world effect, not a read-only report. Second, the credentials embedded in the agent are typically higher trust than SaaS credentials, because agents call the model provider, the vector store, the ticketing system and the code repository on the operator's behalf. Third, the exfiltration primitive is the model itself. A hijacked flow can be told in plain English to enumerate secrets and post them to an attacker-controlled endpoint.

What the KEV listing actually forces

Every US federal agency with a Langflow instance had until 10 July 2026 to patch or pull. That is the operational reading. The strategic reading is different. CISA's KEV catalogue is used by the UK National Cyber Security Centre, by CERT-EU, by the Australian Signals Directorate, by the Singapore Cyber Security Agency and by every serious enterprise procurement team as the reference list of vulnerabilities that must be tracked and closed on a clock. A KEV entry is an admission that the class of software has crossed a line. The class here is internet-exposed AI agent orchestrator. Regulated buyers now have to answer a procurement question they did not have to answer six months ago. Namely, where is our agent runtime, and can any authenticated user of the hosting service reach it?

The only defensible shape is per-tenant, on the tenant's hardware

The answer that survives audit is simple to state and harder to build. The agent runtime runs on hardware the customer owns. It is not shared with another customer. It has no route to the public internet unless the customer explicitly opens one. Every action the agent takes is signed, at the moment of execution, into a tamper-evident record the customer can verify offline. The credentials the agent uses are held on the customer's key store, not in a vendor database. The model the agent calls is the customer's model, running on the customer's silicon, not a shared inference endpoint. This is not a hypothetical shape. It is the shape we ship with MICKAI as a Sovereign Intelligence Operating System. Agent flows execute inside a studio that runs inside the operating system, on the customer's own servers, per tenant, with the Open Audit Record recording every consequential action for offline verification.

What a regulated agent architecture looks like, side by side

The precedent this sets for the rest of the year

CISA does not add categories to KEV lightly. The Langflow entry is the first AI agent framework on the list, and it will not be the last. Every framework that follows the same shape, a shared hosted control plane with embedded credentials, is one missing ownership check from the same listing. Regulated procurement teams should read the 7 July 2026 entry as the moment the burden of proof shifted. From now on the vendor has to explain why the orchestrator is safe to host, rather than the buyer having to explain why it is not. The plain reading of the KEV catalogue is that internet-reachable multi-tenant AI orchestrators do not clear that bar today.

Which Langflow versions are affected by CVE-2026-55255?

All Langflow builds prior to 1.9.1. Upgrading to 1.9.1 or later fixes the missing ownership check on the /api/v1/responses endpoint. Instances that were exposed before the upgrade should be treated as compromised, with every embedded API key, LLM provider credential and cloud secret rotated.

Did the KEV entry mean US federal agencies had to remove Langflow?

The KEV directive gave agencies until 10 July 2026 to patch to a fixed version or discontinue use. Discontinuing use is the safer default where the agency cannot prove no exposed instance existed during the exploitation window that started on 22 June 2026.

Is running an agent framework on customer hardware enough by itself?

No. On-premise deployment removes the shared-tenant blast radius, but the runtime still needs signed actions, an offline-verifiable audit record, credential isolation and a defined update path. Without those, an on-premise agent is a private single-tenant version of the same class of bug.

Where does an AI agent framework belong in a regulated enterprise architecture?

Inside the tenant's own perimeter, on hardware the tenant owns, with no path to the public internet by default. The framework should sit under a signed audit record that any outside auditor can verify offline. Credentials, model weights and tool bindings should be held by the tenant, not by the framework vendor. That posture removes the shared-tenant blast radius, keeps supervisory access on the tenant's side of the trust boundary, and makes CISA-catalogued shared-orchestrator vulnerabilities a vendor problem instead of a customer problem.

What is MICKAI?

MICKAI is a British-built Sovereign Intelligence Operating System. It runs entirely on hardware the customer owns, on premise and air-gapped, with no data egress. Every consequential action is signed into the Open Audit Record, a post-quantum, tamper-evident ledger any outside party can verify offline in a browser. MICKAI ships 63 studios on one operating system, with 10 production-ready at launch and 53 in development, and is protected by 104 filed UK patent applications across 2,340 claims.