CVE-2026-55255: Langflow's IDOR Flaw and the AI Agent Platforms Nobody's Patching

If your team has been experimenting with Langflow to prototype AI agents or RAG pipelines, today is the day to check your version number. CISA added CVE-2026-55255, an authorization bypass in Langflow, to its Known Exploited Vulnerabilities catalog on July 7, and set July 10, today, as the remediation deadline for federal civilian agencies. Attackers have been exploiting it since at least June 25.

What the bug actually does

Langflow is an open-source visual builder for AI agent and RAG workflows, popular with teams that want to wire up LLM pipelines without writing glue code by hand. CVE-2026-55255 is an insecure direct object reference, IDOR for short, in its /api/v1/responses endpoint. Every flow in Langflow has a flow_id, a UUID that identifies it. The endpoint is supposed to check that the requester actually owns the flow they’re asking about. It doesn’t check that thoroughly enough.

An authenticated attacker, meaning anyone with a valid login on the instance, not an admin, can send a crafted request containing another user’s flow_id and get access to that flow: its configuration, its stored credentials, and the ability to execute it. On a single-tenant deployment where everyone using the instance already trusts each other, that’s a smaller problem. On any multi-tenant or shared Langflow instance, and a lot of teams run exactly that setup because it’s the easy way to give a whole department access to agent-building tools, it means one authenticated account is enough to reach into every other user’s flows.

Why this one moved fast

Sysdig’s Threat Research Team first observed exploitation in the wild on June 25, 2026, roughly two weeks before CISA’s KEV addition. What they saw wasn’t reconnaissance. The objective was code execution and second-stage implant delivery, the loader and dropper class of payload that gets a foothold and then pulls down whatever comes next. The attackers used the cross-tenant IDOR specifically to steal LLM provider keys and AWS credentials stored inside flows.

That detail matters more than it might look like at first read. Langflow flows are configuration by design, they hold the API keys and connection strings a workflow needs to actually call an LLM provider or write to cloud storage. A tool built to make AI workflows easy to assemble is, structurally, a tool that concentrates credentials in one place. An IDOR against that kind of system isn’t just an access-control bug, it’s a credential-harvesting bug wearing an access-control bug’s CVE number.

Who’s affected and what to do

All Langflow versions before 1.9.2 are affected. The fix is straightforward:

pip install --upgrade langflow
langflow --version  # confirm you're on 1.9.2 or later

But patching the version number isn’t the end of the response here, and treating it as the end is the mistake most teams will make under deadline pressure. Because the vulnerability let attackers read and execute other users’ flows before you patched, you need to treat every credential stored in every flow on that instance as potentially exposed:

• Rotate every LLM provider API key (OpenAI, Anthropic, Google, or whatever your flows call out to) referenced in any flow configuration.
• Rotate any AWS or other cloud provider credentials stored in flow environment variables or connection nodes.
• Review authentication logs for the window since June 25 for accounts making requests to /api/v1/responses with flow_id values that don’t belong to them.
• Do this even on instances where you don’t have specific evidence of compromise. The whole point of an IDOR is that it doesn’t leave the kind of obvious trace a brute-force attack does.

The bigger pattern: agent platforms are becoming a target class

Langflow is one of the first AI agent-building platforms to land on CISA’s KEV catalog, and that’s worth sitting with for a second. For the last two years, most of the security conversation around LLM tooling has been about prompt injection and model behavior. This CVE is a reminder that the plumbing underneath, the platforms teams use to wire agents together, are ordinary web applications with ordinary web application bugs, IDOR being one of the oldest classes in the book. They just happen to be ordinary web applications that now hold the keys to your model provider account and your cloud infrastructure in one place.

If your team is standing up any kind of internal AI agent platform, whether that’s Langflow, a homegrown builder, or something adjacent to the MCP servers pattern, the access-control model deserves the same scrutiny you’d give a system holding customer payment data, not the lighter scrutiny an internal prototyping tool usually gets. The credentials living inside these tools are frequently more valuable to an attacker than what they’re nominally protecting.

Patch to 1.9.2 today if you’re running Langflow. Then go rotate keys, because the patch closes the door but doesn’t un-steal anything that already walked out of it. And if your team is also handing coding agents autonomous execution permissions, a separate proof-of-concept published this week is worth reading too, since it’s the same underlying lesson from a different angle: AI tooling that’s convenient by default often hasn’t earned the trust that default implies.