📢 New post: Langflow Is Back on the KEV — and This Time It's the Wall Between Tenants: CVE-2026-55255 · 📝 Also fresh: The Doors Open Today: 20x Marketplace Listings, and Three Weeks to Say Goodbye to FedRAMP Ready · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
AI SecurityFedRAMPConMonCISA

Langflow Is Back on the KEV — and This Time It's the Wall Between Tenants: CVE-2026-55255

Back in May we wrote about the KEV item being your agent platform — Langflow, the open-source visual builder teams use to wire up LLM workflows and multi-agent applications. That one (CVE-2025-34291) was an account-takeover-to-RCE chain: permissive CORS, a missing CSRF check, and a code-validation endpoint that ran user-supplied Python by design.

On July 7, CISA added CVE-2026-55255 — Langflow again. The federal remediation deadline is July 10, three days out, and it's on the catalog because it's being exploited in the wild.

Two Langflow KEV items in six weeks is worth pausing on. But the more useful observation is that this one broke a different thing. The May bug was code execution — the classic "attacker runs their code on your host" story. This one doesn't need code execution at all. It's an authenticated user reaching across the boundary into flows that belong to someone else. The thing that failed is tenant isolation, and that's a quieter, more insidious kind of failure.

The mechanism

Langflow exposes an OpenAI-compatible responses endpoint at /api/v1/responses. You hand it a flow ID and it runs that flow. Underneath, the request resolves the ID through a helper — get_flow_by_id_or_endpoint_name — that, when handed a UUID, queries the database directly for that flow and returns it.

The bug is what the helper doesn't do: it never checks whether the authenticated caller actually owns the flow it just looked up. So any logged-in user who knows (or guesses, or enumerates) another user's flow ID can invoke that flow as themselves. That's an Insecure Direct Object Reference — CWE-639, "Authorization Bypass Through User-Controlled Key." The user-controlled key is the flow ID; the authorization that should have gated it isn't there.

It's about as ordinary as web vulnerabilities get. No exotic chain, no memory corruption — just a missing ownership check on an object lookup. The vendor's advisory (GHSA-qrpv-q767-xqq2) scores it 9.9 (CVSS 3.1) with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L; NVD's own analysis is still pending, so expect the authoritative score to settle over the next few days. What earns the high number is the scope change (S:C) — the attack crosses from the attacker's authorization context into the victim's — combined with low attack complexity and no user interaction. You need an account, and that's the only real hurdle.

Affected versions are everything before 1.9.1. The fix landed in 1.9.1 (PR #12832), which adds the ownership check the helper was missing. If you run Langflow with more than one user or tenant, "upgrade to 1.9.1 or later" is the whole remediation — but read on for why the upgrade isn't the end of the work.

Why an authorization bypass is worse than it sounds on an agent platform

On an ordinary app, an IDOR usually leaks a record — someone reads an invoice they shouldn't. On an orchestration platform, a flow isn't a record. It's executable. Running another user's flow means running their wired-up chain of tool calls, model invocations, and data connections — with whatever credentials and integrations that flow carries.

We made this point about the May bug and it holds double here: orchestration tools accumulate high-value credentials by design. A flow that pulls from a vector store, writes to a database, or calls a paid model API does so using secrets the platform holds. Execute someone else's flow and you're not just seeing their work — you're spending their credentials and touching their data, from inside a session the platform believes is legitimately yours.

That's the part that makes this a governance problem and not only a patching problem. This is exactly the boundary separation of duties exists to protect: one principal's actions should not silently execute under another principal's authority. A multi-tenant AI platform where any tenant can run any tenant's flows has, functionally, no separation between tenants at all.

If you're inside a FedRAMP boundary

The KEV-clock mechanics are the ones we've walked through several times now — a catalog entry inherits a federal due date, and that date overrides the comfortable 30/90/180-day continuous-monitoring windows. July 10 is the date that matters here. And as of BOD 26-04, the triage question isn't "what's the CVSS?" but "is it exposed, is it automatable, does it grant control, is it being exploited?" This one answers yes to exploited outright, and yes to automatable — enumerating flow IDs and replaying a request is trivially scriptable — so it lands high in the urgency bands regardless of where NVD finally sets the number.

What's specific to this CVE is the shape of the question it forces, and it's a different question than an RCE asks:

  • Is your Langflow multi-tenant, and did you think it was? A single-user instance isn't exposed to this the same way — there's no other tenant to reach. The risk lives wherever multiple users or teams share one deployment. If you stood Langflow up as a "shared internal tool," you are the multi-tenant case, whether or not anyone called it that.
  • Tenant isolation is a control, and this is a finding against it. FedRAMP boundaries lean on information-flow and access enforcement (SC-4, AC-3/AC-4) to keep tenants apart. An authorization bypass that lets one tenant execute another's flows is a direct hit on those controls — document it as such, not just as "a vuln we patched."
  • Assume cross-tenant execution already happened. With active exploitation confirmed, the question isn't only "are we patched" but "did anyone run a flow that wasn't theirs before we patched?" That's an access-review and log-analysis task: which flow IDs were invoked, by which principals, against whose flows. Any flow whose credentials could have been exercised by the wrong user is a rotation candidate.
  • The evidence trail is the durable artifact. Same as ever — the version before and after, the access-log review, the POA&M entry if you opened one, the rotation tickets for anything that ran under a borrowed identity. The assessment remembers the trail, not the scramble.

What we keep coming back to

The unglamorous inventory question is the one that decides whether July 10 is a normal Wednesday: do we run Langflow anywhere inside the boundary, at what version, shared by whom? If the honest answer is "we'd have to go ask around," the three days are already shrinking — and the follow-on question this CVE adds is sharper than usual, because it's not about a box you patch, it's about a boundary you assumed was holding: on your shared AI platforms, is one tenant actually walled off from another — or is that isolation something you've been trusting without ever testing?

The May Langflow post ended on credentials; this one ends on tenancy. They're the same lesson from two sides. An orchestration platform aggregates secrets and mediates between the people who use it, and both of those are load-bearing walls. It's the shape of work we've been building the Novaprospect audit engine toward — infrastructure-native discovery that finds the shared system you forgot to write down, and evidence collected as a normal byproduct so the access review is a query, not an archaeology dig.

Reference