On 7 July 2026 CISA added CVE-2026-55255 to the Known Exploited Vulnerabilities catalog and set a deadline of 10 July. It is an insecure direct object reference in Langflow's /api/v1/responses endpoint: a logged in user can run any other user's flow just by knowing its ID.
The fix was merged on 22 April 2026. The GitHub advisory was published on 19 June, and NVD followed on 23 June, so the exploitation signal came about two and a half weeks after the advisory.
What's affected
The langflow Python package before 1.9.1. The advisory (GHSA-qrpv-q767-xqq2) rates it 9.9 Critical, while NVD scores it 8.4 High, because their vectors rate attack complexity differently (low in the advisory, high in NVD). The weakness is CWE-639, authorization bypass through a user controlled key.
Some third party pages say the fix landed in 1.9.2. The advisory and NVD both say 1.9.1, so 1.9.1 or later is the floor. Moving to the newest release is the safer habit anyway.
How the bug works
A helper named get_flow_by_id_or_endpoint_name finds a flow either by endpoint name or by UUID. The endpoint name branch checked that the flow belonged to the caller. The UUID branch queried the database with no ownership check. So a request to /api/v1/responses carrying a victim's flow ID returned 200 and ran the victim's flow.
The advisory lists the impact: running other users' flows, reaching data those flows process, and spending the victim's resources. A flow in Langflow can call models, tools and databases, so running it is more than reading a record.
The fix, in pull request 12832, enforces ownership in both lookup branches. Cross user lookups now return 404 instead of 403, so the response does not even confirm that the flow exists.
How to check if you're exposed
pip show langflow | grep -i '^version'
docker run --rm <image> pip show langflow | grep -i '^version'
If you run a shared instance, find out who has accounts. Self registration on an internet facing server means every visitor is an "authenticated user". Then look in your proxy logs for calls to the route:
grep 'POST /api/v1/responses' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head
One user hitting the route with many different flow IDs is worth a closer look.
The two lookup branches side by side
| Lookup by | Ownership check before the fix | After the fix (1.9.1) |
|---|---|---|
| Endpoint name | Yes, filtered on the caller's user_id | Yes |
| Flow UUID | No, the query took the ID and returned the flow | Yes, same filter |
| Wrong owner | Flow ran and the endpoint returned 200 | 404, so existence is not revealed |
Malformed user_id | 500 error | 404 |
The last two rows matter for defenders. Returning 404 instead of 403 means a probing user learns nothing about which IDs are real, and a malformed value no longer produces a stack trace.
If you run Langflow in Docker, pin the image by tag or digest and record which one is live, so "are we on 1.9.1" is a lookup and not an investigation:
docker ps --format '{{.Names}} {{.Image}}' | grep -i langflow
docker image inspect <image> --format '{{index .RepoDigests 0}}'
You can also write the regression test for your own services. For any endpoint that takes an object ID, create two users, create an object as user A, request it as user B, and assert a 404. It takes ten lines and catches this class of bug before a release.
What to do now
- Upgrade Langflow to 1.9.1 or later and rebuild container images.
- Turn off open sign up unless you need it, and prune accounts that no longer belong to anyone.
- Rotate secrets that flows on shared instances can reach: model provider keys, database passwords, tool tokens.
- Review flow run history on shared instances for runs triggered by users who do not own the flow.
- Put the instance behind your SSO and keep it off the public internet.
How this could have been avoided
- Authorize at the lookup, every time. The fix is a single rule: any query that takes an ID from the client must also filter on the caller. One branch had it, the other did not. A shared data access helper that always requires a user argument makes the mistake hard to write.
- Test both paths. A test that requests a flow by UUID as the wrong user would have failed. Authorization tests belong next to every endpoint that accepts an identifier.
- Do not treat unguessable IDs as access control. UUIDs leak through logs, shared links and screenshots.
- Isolate tenants. Separate Langflow instances, or at least separate credentials per team, keeps one account's mistake from reaching another team's keys.
- Close sign up. An IDOR needs a login. Limiting who can have one shrinks the exposed group.
Why it matters
AI workflow builders hold a lot of power in one place: model keys, vector stores and tool access, all behind a web form. Broken authorization in such a tool is not a data leak in the usual sense. It is the ability to act as another person's agent.
The score gap here is a useful reminder. A 9.9 from the vendor and an 8.4 from NVD both ended up on the same urgent list, because KEV tracks use in the wild, not arithmetic.
Reading the advisory dates
Three dates tell a useful story. The fix was merged on 22 April, the advisory appeared on 19 June, and exploitation was confirmed enough for KEV on 7 July. Teams that track only released advisories had no warning for the first eight weeks. Teams that track the upstream repository's merged security fixes could have moved sooner.
If your Langflow instance is internal only, the risk shrinks but does not vanish. Any employee with an account could run a colleague's flow, and flows often carry production keys. Treat internal as lower exposure, not as safe. A quick inventory of who holds an account, and which of them still work at the company, is the cheapest control on this list.
Try it yourself
List every AI orchestration tool in your company: Langflow, workflow builders, agent frameworks, notebooks with model keys. For each one, write down who can log in and which credentials it can reach.
Click through it at your own pace, or open it full screen.
Quick check
Why did the UUID lookup branch matter?
It skipped the ownership check that the endpoint name branch performed, so a valid flow ID was enough to run someone else's flow.
Which version fixes CVE-2026-55255?
Langflow 1.9.1 per the GitHub advisory and NVD. Use 1.9.1 or later.
