CISA has added CVE-2026-55255, a flaw in the popular AI-agent builder Langflow, to its Known Exploited Vulnerabilities catalog, marking the first time an AI agent orchestration platform has appeared on the list. The bug is a cross-tenant insecure direct object reference (IDOR) that lets an authenticated attacker run another user's flows and read the data they process. Its official CVSS is a modest 6.1, but security firm Sysdig watched attackers use it in the wild to steal LLM provider keys and AWS credentials, and CISA set a federal patch deadline of July 10.
- First of its kind. Langflow is the first AI agent platform to enter CISA's KEV catalog, a milestone for where attackers are now looking.
- The flaw. CVE-2026-55255 is an IDOR at the
/api/v1/responsesendpoint: send another user's flow UUID and you run their flow and read its data. - Why the low score misleads. On multi-tenant deployments the IDOR is the one path that crosses to another customer's credentials, and it leaves almost no trace in logs.
- Fix and rotate. Update to Langflow 1.9.2+, then rotate every API key, LLM credential and cloud key stored in any flow, exploited or not.
What is the vulnerability?
Langflow is a visual framework for wiring up AI agents, and instances routinely store the credentials those agents need: OpenAI and Anthropic API keys, cloud access keys, database connection strings. CVE-2026-55255 is an authorization-bypass-through-user-controlled-key flaw, the classic IDOR shape. An authenticated user sends a crafted request to the /api/v1/responses endpoint with a victim's flow UUID, and because the server does not verify ownership, it executes that flow and returns the sensitive data it touches. In practice a compromised Langflow instance is less a code-execution target and more a credential vault for a chunk of an organization's AI stack.
RelatedFortiBleed: Hacked Fortinet Firewalls Fuel a Ransomware Wave
Why does a CVSS 6.1 flaw make the KEV?
Because the score understates the real risk. Three of the four flaws CISA added that day carry perfect 10.0 scores, and next to them a 6.1 looks minor. But Sysdig's threat team observed CVE-2026-55255 exploited in the wild starting June 25, chained after the separate CVE-2026-33017 RCE, with the goal of stealing LLM and cloud keys. On a single-tenant box the RCE is the easier win, but on a managed or multi-tenant Langflow deployment where RCE is sandboxed per tenant, the IDOR is the only path that reaches another customer's secrets, and it does so below most detection thresholds. A successful hit looks like normal flow execution except for a mismatched flow ID in the logs. KEV entry means the exploitation is confirmed, which is exactly why CVSS alone is a bad prioritization signal here.
Who is affected and what should they do?
Anyone running a self-hosted or managed Langflow instance, especially one that was ever internet-accessible, should treat this as urgent. The remediation is specific: update to Langflow 1.9.2 or later, then rotate every API key, LLM provider credential and cloud access key stored in any flow, even with no evidence of compromise. Audit /api/v1/responses access logs for cross-user flow-ID patterns. If the instance was exposed to the internet, treat credential rotation as mandatory, not precautionary, because the whole point of this flaw is that it steals secrets quietly.
- AI tooling as a target class. Langflow is the first AI-agent platform on KEV. It will not be the last, because these tools concentrate credentials by design.
- Repeat exposure. This is the latest of several Langflow flaws exploited in the past year, including one used by the JADEPUFFER agentic-ransomware operation.
- Prioritize with KEV + EPSS. Confirmed exploitation and exploit-probability beat a raw CVSS number for patch triage.
- Credential hygiene. Storing long-lived provider and cloud keys inside dev tools is the underlying weakness attackers keep monetizing.
What does this mean for anyone running AI tooling?
The practical takeaway extends well past Langflow. Any self-hosted AI tool that stores provider keys is now a named target class, so the defensive posture has to change. Scope every API key to the minimum it needs, prefer short-lived tokens over long-lived secrets, keep these tools behind authentication and off the public internet, and put credential-access logging where you will actually notice an anomaly. The uncomfortable truth is that a single exposed instance can hand an attacker the keys to your entire model budget and cloud account, and that risk exists whether or not a specific CVE is public today. Treat every AI-orchestration box as a production credential store, because that is what it is.
RelatedMicrosoft Patches RoguePlanet Defender Zero-Day
Our take
The milestone matters more than the single CVE. Attackers have figured out that AI development tools are soft, high-value targets: they sit exposed, they hold the keys to expensive model APIs and cloud accounts, and their operators often treat them as internal prototypes rather than production systems. A "medium" IDOR that leaks your OpenAI and AWS keys is not medium in any way that matters. If you run Langflow, patch and rotate today. If you run any AI-orchestration tool, take the broader lesson: stop parking long-lived credentials inside it, scope keys tightly, keep it off the public internet, and watch its logs like the credential store it actually is.
- AdvisoryCISA KEV catalog the authoritative exploited-vulns list
- ResearchSysdig Threat Research in-the-wild exploitation of CVE-2026-55255
- ReportingBleepingComputer CISA order and deadline
- ReferenceGenZTech CVE Watchlist tracked high-impact flaws
Original analysis by GenZTech. Reporting via BleepingComputer.
