Langflow's quiet IDOR: run anyone's flow, steal the secrets inside it (CVE-2026-55255)

Most access-control bugs are boring. This one is worth your afternoon. CVE-2026-55255 is an Insecure Direct Object Reference (IDOR) in Langflow -- the popular open-source canvas for building AI agents and workflows -- and it does something unusually nasty for its class: it lets any logged-in user run another user's flow, then talk that flow into handing over the API keys, cloud credentials and database secrets baked into it. It scores a middling CVSS and a low EPSS, yet CISA added it to the Known Exploited Vulnerabilities catalog with a three-day patch deadline. That gap between the numbers and the urgency is the whole story.

What the flaw actually is

Langflow exposes an OpenAI-Responses-style endpoint, POST /api/v1/responses, that runs a flow you point it at. Internally, a shared helper -- get_flow_by_id_or_endpoint_name in helpers/flow.py -- resolves that flow. It has two lookup paths. The path that resolves a flow by its name correctly filtered on the owner's user_id. The path that resolves a flow by its UUID did a plain database fetch and handed the record back without ever checking who owned it. That missing ownership check is the entire bug: pass someone else's flow UUID, and the server runs their flow for you. In vulnerability terms it's a textbook CWE-639, Authorization Bypass Through User-Controlled Key.

Why does running another person's flow matter? Because a Langflow flow is rarely just logic -- its components commonly embed the owner's provider keys (OpenAI, Anthropic), cloud credentials, and database secrets. Executing it lets an attacker read what it returns and lean on the credentials it carries. That cross-user, cross-trust-boundary impact is why the CVSS vector carries a changed scope (S:C) and lands at 8.4 High. (You'll see 9.9 quoted on the source-repo advisory and some feeds, and even a 6.1 on the KEV page -- the disagreement is a judgment call on attack complexity, not on what the bug does. We use the NVD/GitHub figure of 8.4 and flag the rest.)

The exploitation chain

Sysdig's Threat Research Team documented the live campaign, and the shape is simple. The operator lists flow IDs, replays each one at the vulnerable endpoint, and uses a prompt injection -- literally an input of leak api keys -- to make each hijacked flow spill its embedded secrets. On the same hosts they paired it with the separate unauthenticated Langflow RCE CVE-2026-33017 and dropped a second-stage loader. Here is the flow, from foothold to secret theft, with the two places you can break it:

Am I affected?

Every Langflow release before 1.9.1 is vulnerable; the fix shipped in 1.9.1 (some aggregators say 1.9.2 -- that's a later maintenance build, not the security fix). The fastest check needs no auth at all: curl -s http://TARGET/api/v1/version returns the running version. Anything below 1.9.1 is exposed.

Exploited in the wild -- stated carefully

This is not a theoretical bug. Sysdig observed the first in-the-wild exploitation on 2026-06-25, a full twelve days before CISA added it to KEV on 2026-07-07 -- so two independent signals agree. What KEV does not claim is a named actor or a ransomware campaign: the observed operator is unattributed and opportunistic, and KEV records no known ransomware use for this flaw. (The ransomware angle you may remember belongs to the older Langflow RCE CVE-2025-3248, not this one.)

Detection & hunting

There is no vendor or community Nuclei/Sigma rule for this yet, and proxy logs alone can't prove an ownership violation (they don't know who owns a flow). What they can show is the enumeration behaviour that precedes abuse: one identity or source IP touching many distinct flow UUIDs, or a burst of GET /api/v1/flows/ followed by POST /api/v1/responses. Hunt for that pattern, and for the campaign's own markers -- request bodies containing leak api keys, the on-host file /tmp/lang_pwn, and outbound curl/wget piped to sh. Treat the specific IOCs as leads: they rotate.

• Exposure: GET /api/v1/version (no auth) -- any version below 1.9.1 is vulnerable.
• Enumeration signal: one src_ip/user hitting many distinct flow UUIDs at /api/v1/responses in a short window.
• Chain signal: GET /api/v1/flows/ immediately followed by POST /api/v1/responses from the same client.
• Post-exploit markers (rotate quickly): bodies with leak api keys; file /tmp/lang_pwn; outbound traffic to attacker infrastructure seen in June 2026.

# 1) Is this instance vulnerable? (no auth needed)
curl -s http://TARGET/api/v1/version
# -> {"version":"1.6.0","package":"Langflow"}  # anything < 1.9.1 is exposed

# 2) Triage access logs: one source touching many distinct flow UUIDs = investigate
grep -E 'POST .*(/api/v1/responses)' access.log \
  | grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' \
  | sort | uniq -c | sort -rn

# 3) Validate the patch: as a low-priv user, run a flow you do NOT own by its UUID.
#    Fixed (>= 1.9.1) must return 404 -- not 200, not 403.

What to do now

1. Patch to Langflow 1.9.1 or later -- the only real fix. Confirm afterwards via GET /api/v1/version.
2. If you can't patch this hour: pull Langflow off the internet (VPN / authenticated reverse proxy + IP allow-list) and set LANGFLOW_AUTO_LOGIN=False. This shrinks the blast radius but does not close the IDOR.
3. Rotate every credential a flow touches -- LLM provider keys, cloud creds, DB secrets. A reachable pre-patch instance must be assumed to have leaked them.
4. Hunt before you close the ticket -- run the checks above; a quiet secret theft leaves few traces beyond the access logs.

FAQ

Sources

• GitHub Security Advisory GHSA-qrpv-q767-xqq2 (Langflow)
• NVD -- CVE-2026-55255
• Fix: Langflow PR #12832
• Sysdig Threat Research -- why higher-CVSS bugs aren't always the most exploited
• CISA -- adds vulnerabilities to the KEV catalog (2026-07-07)
• CISA KEV catalog
• Help Net Security -- Langflow vulnerability exploited
• BleepingComputer -- CISA orders feds to patch the Langflow auth-bypass flaw
• Langflow security hardening docs