Kai Ole Hartwig
8 min read
Critical

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?

AffectedNot affectedConditions
Langflow instances before version 1.9.1Langflow 1.9.1 and later
Multi-tenant deployments (multiple users/teams with their own flows)Strictly single-user instances with no other accountsAttacker needs a valid, authenticated account — no unauthenticated access required
Flows with stored API keys/cloud credentialsFlows without sensitive secretsImpact 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

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.

Sources

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.

About the author

[Translate to English:] Foto von Kai Ole Hartwig.

Kai Ole Hartwig

Freelance DevSecOps consultant · OnlyOle Consulting

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.

Langflow, CVE-2026-5027, path traversal, arbitrary file write, RCE, unauthenticated, auto-login, AI agents, AI builder, low-code, agent frameworks, LLM tooling, self-hosted, exposed instances, VulnCheck, Tenable, Censys, DevSecOps, supply chain, Mittelstand

Langflow CVE-2026-5027 (Path Traversal → RCE)

CVE-2026-5027 (CVSS 8.8) is a path traversal in the Langflow file upload (POST /api/v2/files): the filename parameter from the multipart body is not sanitised, so files can be written to arbitrary locations via ../ sequences. Because Langflow enables unauthenticated auto-login by default, a single request without credentials is enough to reach RCE. Tenable disclosed the flaw on 27 March 2026 (TRA-2026-26), fixed in Langflow 1.9.0 on 15 April 2026; VulnCheck reports active in-the-wild exploitation since 10 June (so far benign test files). Censys: ~7,000 publicly reachable instances, mostly in North America. Architectural lesson: an AI build tool is a production, internet-facing service holding privileged secrets — patching closes the spot, exposure control plus enforced authentication plus inventory close the class.

LangGraph, LangChain, CVE-2026-28277, CVE-2025-67644, CVE-2026-27022, checkpointer, SQLite, Redis, RediSearch, msgpack, deserialization, SQL injection, RCE, AI agents, agent frameworks, self-hosted, get_state_history, DevSecOps, supply chain, Mittelstand

LangGraph checkpointer chain (CVE-2026-28277)

Three LangGraph flaws disclosed by Check Point Research on 12 June 2026 hit the memory layer (checkpointer) of stateful AI agents. CVE-2025-67644 (CVSS 7.3): SQL injection in the SQLite checkpointer via metadata filter keys. CVE-2026-28277 (6.8): unsafe msgpack deserialization on checkpoint load. Chained they yield RCE in the agent's runtime context — the SQLi inserts a forged checkpoint row with an attacker-controlled BLOB that the decoder reconstructs. CVE-2026-27022 (6.5): RediSearch query injection in the Redis checkpointer (access-control bypass). Precondition: self-hosted, exposed get_state_history() path, user-controlled filter; LangSmith-hosted is not affected. Architectural lesson: an AI agent is a privileged identity — patching closes the spot, a filter allow-list + a sealed write path + least privilege close the class. Fix: langgraph 1.0.10 / -sqlite 3.0.1 / -redis 1.0.1.

[Translate to English:] AI Agent, LLM, Prompt Injection, LiteLLM, Flowise, MS-Agent, CVE, DevSecOps, KI-Sicherheit

When the AI agent becomes a privileged insider: three current CVEs in LiteLLM, Flowise and MS-Agent

Three CVEs from spring 2026 make the structural problem of productive AI agents concrete: SQL injection in LiteLLM, prompt-injection RCE in Flowise CSV agent, OS command hijacking in MS-Agent. What the incidents share, and which four architectural principles absorb them structurally.