Langflow's cross-tenant flow hijack: the 9.9 bug attackers ignored

What is this?

On June 26, 2026, Sysdig’s Threat Research Team published the first documented in-the-wild exploitation of a cross-tenant flaw in Langflow, the open-source visual framework for building AI agents and RAG pipelines. The bug is a cross-tenant insecure direct object reference (IDOR): an authenticated user can execute another user’s flow — and inherit the secrets embedded in it. It carries a CVSS score of 9.9, higher than the unauthenticated remote-code-execution flaw exploited alongside it, which scores 9.3.

The interesting part is what the attacker didn’t do. Sysdig observed a single operator, on June 25, 2026, run both flaws against the same internet-exposed instance. They poured sustained effort into the lower-scored RCE and treated the higher-scored cross-tenant bug as a two-request afterthought. This is a class-of-vulnerability writeup and a lesson in reading CVSS scores, not an actionable exploit — both flaws are patched.

How it works

Langflow exposes each flow as a callable “model” through an OpenAI-compatible endpoint. A request to POST /api/v1/responses names a flow by its UUID in the model field. The flaw lived in the flow-lookup helper: when a flow was resolved by UUID, the database query ran with no ownership check, so any authenticated caller could execute any user’s flow. The parallel path that resolves a flow by its endpoint name did enforce ownership — only the UUID branch was exposed.

Step        What the operator did
----------  ---------------------------------------------------
Enumerate   GET /api/v1/flows/  — a list endpoint that
            over-shares other users' flow UUIDs.
Hijack      POST /api/v1/responses  with model:<victim-flow-id>
            and a prompt injected as input, e.g. "[REDACTED:
            credential-surfacing instruction]".
Yield       The victim's flow runs with the victim's embedded
            keys; the injected prompt coaxes them into output.

A flow UUID is random and 122 bits wide, so it cannot be brute-forced. That is the whole story of this bug: on its own it is inert. It only becomes reachable because the list endpoint hands out the very identifiers the attack needs. The fix, shipped in Langflow 1.9.1, adds the missing ownership check to the UUID path.

Why it matters

On a single self-hosted box, this cross-tenant flaw does nothing the neighbouring RCE can’t already do — once you have unauthenticated code execution, you own the process, database, filesystem and environment outright. That asymmetry is exactly why the RCE was mass-exploited within 20 hours of its March disclosure, hit roughly 7,000 exposed servers, and landed in CISA’s Known Exploited Vulnerabilities catalog, while the higher-scored cross-tenant bug had, until now, zero reported in-the-wild use. Attackers optimise for yield per unit of effort, and an unauthenticated, internet-sprayable RCE wins that trade every time.

The exception is multi-tenant or managed Langflow. There, the RCE runs inside a per-tenant sandbox — reaching another customer requires a sandbox escape. The cross-tenant flaw crosses that boundary at the application layer, through the platform’s own blessed execution path, running the victim’s flow with the victim’s credentials. No host compromise, no escape, and it looks like a legitimate API call whose only anomaly is a “wrong” flow ID. That makes it both higher-impact and quieter in precisely the environment where the RCE is contained. And Langflow flows are worth targeting: they routinely embed LLM provider keys, cloud credentials and database secrets directly in component configs.

Defenses

Nothing here requires a novel control — it requires patching and treating authorization as a data-layer property, not a network one.

1. Upgrade to Langflow 1.9.1 or later, which adds the ownership check. Patch the unauthenticated RCE in the same pass — it is the flaw actually being sprayed at internet scale.
2. Treat object-ID disclosure endpoints as part of the attack surface. The cross-tenant bug is inert without a leaked flow UUID; the over-sharing list endpoint is what arms it. Scope list responses to the caller’s own objects.
3. Do not expose Langflow to the internet, and disable any no-auth or auto-login default. Put it behind authenticated network controls.
4. Multi-tenant operators: enforce authorization at the data layer, not just via sandbox isolation. Give the application-level ownership fix the urgency the 9.9 score implies — sandboxing does not stop an app-layer tenant break.
5. Stop embedding long-lived secrets in flow configs. Use short-lived, scoped credentials from a secret manager, and rotate any keys that lived in an exposed instance.
6. Add runtime detection for flow enumeration followed by cross-owner execution, and for prompt inputs whose intent is to surface credentials.

Status

Item	Reference	Date	Notes
Cross-tenant flow hijack	CVE-2026-55255	2026	CVSS 9.9 IDOR; fixed in Langflow 1.9.1
First in-the-wild use	Sysdig TRT	2026-06-25	Enumerate → hijack, 2 requests; no prior exploitation
Sibling unauth RCE	CVE-2026-33017	2026-03	CVSS 9.3; CISA KEV 2026-03-25; ~7,000 servers hit
Public research	Sysdig TRT	2026-06-26	Side-by-side effort analysis of both flaws

The takeaway is not that a higher CVSS score is wrong — it is that a score measures worst-case impact, not exploitability. A 9.9 that needs authentication, a leaked object ID and a multi-tenant target loses, in practice, to a 9.3 that anyone can reach with nothing but network access. Patch both, but read the score for what it is.