Langflow CVE-2026-55255: IDOR lets attackers run other users' AI flows — first AI agent platform in CISA KEV
Langflow is the first AI agent platform to ever land on CISA's Known Exploited Vulnerabilities catalog: CVE-2026-55255 (CVSS 8.4), disclosed on 8 July 2026 and added to the KEV catalog by CISA a day earlier, on 7 July. The flaw is a classic IDOR (insecure direct object reference) — authenticated attackers can execute another user's flows simply by specifying that user's flow ID in the request. In multi-tenant deployments, that's a direct path to API keys, AWS credentials, and other secrets stored in someone else's flows. CISA gave affected federal agencies a remediation deadline of Friday, 10 July 2026. Fix: Langflow 1.9.1. Note: this is a different vulnerability from CVE-2026-5027 (path traversal → RCE, 30 June 2026), already covered on this blog — same platform, two distinct flaws.
TL;DR — 90 seconds
Affected?
All Langflow versions prior to 1.9.1, particularly multi-tenant deployments where multiple users create their own flows.
Risk?
IDOR/authorization bypass (CVSS 8.4): an authenticated attacker can execute another user's flows by specifying that flow's ID — including access to API keys and cloud credentials stored within it. Actively exploited per CISA.
Immediate action?
Update to Langflow 1.9.1 or later. CISA gave affected US federal agencies a deadline of 10 Jul 2026 — a useful general urgency signal for other operators too.
Recommendation?
Anyone running Langflow multi-tenant should additionally treat all secrets stored in flows (API keys, cloud credentials) as potentially compromised and rotate them, regardless of when they patch.
Criticality?
critical (hero badge) — CISA KEV listing, active exploitation, first AI agent platform in this catalog.
What is the problem?
Langflow is a visual builder for AI agent workflows (“flows”) that frequently reference API keys, database credentials, or cloud access credentials to interact with external services. CVE-2026-55255 is an insecure direct object reference (IDOR): when executing a flow, the application doesn't sufficiently verify whether the requesting — authenticated — user actually has access rights to the specified flow ID. An attacker with a valid but low-privileged account can therefore simply substitute another user's flow ID in the request and have that flow executed — including all secrets and data access configured within it.
The pattern is especially relevant in multi-tenant SaaS or internal self-hosted deployments with multiple teams, since that's exactly where the base assumption “my flow belongs to me, others can't see it” breaks down. CISA confirms active exploitation in the wild.
Who is affected?
Affected
Not affected
Conditions
Langflow instances before version 1.9.1
Langflow 1.9.1 and later
—
Multi-tenant deployments (multiple users/teams with their own flows)
Strictly single-user instances with no other accounts
Attacker needs a valid, authenticated account — no unauthenticated access required
Flows with stored API keys/cloud credentials
Flows without sensitive secrets
Impact scales with the sensitivity of credentials stored in the flow
CISA added the flaw to the KEV catalog on 7 July 2026 — a strong signal of already-ongoing, active exploitation, not just theoretical risk.
Impact
The immediate impact is access to other users' AI workflows along with everything stored in them: API keys for LLM providers, database credentials, cloud credentials (AWS and others), and potentially the results/outputs of others' flow executions. In environments where Langflow serves as a central orchestration layer for multiple teams or customers, this means horizontal privilege escalation across tenant boundaries — a user with minimal privileges can effectively act as any other platform user, as long as they know or guess that user's flow ID. Since flow IDs are often sequential or predictable, guessing valid IDs is not much of an obstacle either.
Mitigation / immediate steps
Note: based on the CISA KEV listing and cited reporting — reconcile details against the official Langflow release notes and CISA advisory.
Operational decision block
Act now if … you run Langflow multi-tenant or with multiple user accounts and aren't yet on 1.9.1.
Check with priority if … you're a US federal agency or supplier — the CISA deadline was 10 Jul 2026.
Monitor only if … you run a strictly single-user instance with no other accounts.
Step 1 — update to 1.9.1
# check current version
pip show langflow | grep Version
# update
pip install --upgrade langflow==1.9.1
# or for container deployments: update the image tag and redeploy
docker pull langflowai/langflow:1.9.1
Step 2 — rotate secrets
- all API keys that were stored in Langflow flows (LLM providers, databases)
- AWS/cloud credentials referenced by flows
- access tokens for downstream systems that flows could reach
Step 3 — restrict access until patched
# temporarily restrict multi-tenant usage if an update isn't immediately possible
# limit network access to the Langflow instance to trusted sources
# enable audit logging to trace flow executions per user
Detection / verification
Check version
pip show langflow | grep Version
docker inspect <container> | grep -i langflow
Check for suspicious flow executions
# check audit/access logs for flow executions with a user/flow-ID mismatch
grep -i "flow_id" langflow-access.log | awk '{print $user, $flow_id}' | sort -u
# unusual access patterns: a user requesting many different flow IDs
Runtime indicators
- flow executions by users who didn't create the flow themselves
- unusual API calls to LLM providers/cloud services outside known usage patterns
- access to secrets/credentials not previously used by that user account
Operator guidance
Mid-market
Update to 1.9.1 and rotate all secrets stored in flows — regardless of whether abuse can be proven. For multi-tenant usage: enable audit logging to catch future anomalies.
Enterprise
Additionally: check whether Langflow serves as a central platform for multiple teams/customers — that's where the blast radius is largest. Reconsider secrets management: instead of storing credentials directly in flows, use external secret stores (Vault, AWS Secrets Manager) with short-lived, scope-limited tokens.
US federal agencies / regulated environments
A CISA KEV listing means binding remediation deadlines for federal agencies (the deadline was 10 Jul 2026) — also relevant as a supplier if contractual compliance requirements apply.
Decision block
Act today if: multi-tenant Langflow without the patch + secrets in flows. Monitor if: single-user, already patched.
Frequently asked questions about CVE-2026-55255
Is this the same flaw as CVE-2026-5027, already covered here?+
No — CVE-2026-5027 (covered 30 Jun 2026) was a file-upload path traversal with unauthenticated RCE. CVE-2026-55255 is a separate IDOR affecting authenticated users. Two distinct flaws in the same platform.
Is a single user account enough to exploit this?+
Yes, per the description a valid, authenticated account with arbitrarily low privileges is sufficient — the attacker only needs to specify another user's flow ID in the request.
What does the CISA KEV listing concretely mean?+
CISA only lists vulnerabilities with confirmed active exploitation in the wild. For US federal agencies, the listing comes with a binding patch deadline (here: 10 Jul 2026); for everyone else, it's a strong urgency signal.
Do I need to rotate all secrets even without evidence of abuse?+
Recommended, yes — with active exploitation in the wild, the absence of explicit evidence isn't reliable proof of safety, especially in multi-tenant usage.
Are single-user instances affected?+
The specific IDOR risk (executing others' flows) presupposes multiple user accounts. A strictly single-user instance with no other accounts isn't affected by this specific attack path — updating to 1.9.1 is still recommended regardless.
How easy are flow IDs to guess?+
That depends on the implementation; sequential or predictable IDs further lower the exploitation bar. Details on the exact ID format aren't specified in the cited sources.
Conclusion
Langflow being the first AI agent platform in the CISA KEV catalog is a milestone with an uncomfortable subtext: AI agent infrastructure is now treated with the same urgency as classic enterprise software — rightly so, since flows often bundle exactly the secrets most valuable for lateral movement. Anyone running Langflow multi-tenant should not just patch, but fundamentally reconsider whether credentials belong directly in flows at all, versus an external secret store with short-lived tokens.
I patch your Langflow instance, rotate affected secrets, and set up clean secrets management for AI flows.
Version update to 1.9.1, rotation of all API keys and cloud credentials stored in flows, migration to external secrets management with short-lived tokens, and audit logging for multi-tenant usage.
Platform operations instead of advice on paper: I continuously check, patch and harden your AI agent infrastructure.
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.