SURIQ
If two teams share one Langflow server, either one can quietly run the other's AI workflows right now. A bug disclosed on June 19 lets any account with a valid API key execute a flow it does not own, simply by knowing that flow's ID. The flows it can reach hold live credentials: model-provider keys, cloud access, database logins. So this is not a read-only peek. It is someone else's automation, running on someone else's secrets, triggered by you.
The flaw is tracked as CVE-2026-55255 and rated 9.9 out of 10. Langflow patched it in version 1.9.1. The more useful thing to notice is that it is not the first time the project has gotten authorization this wrong in 2026, and the pattern is the part worth your attention.
What CVE-2026-55255 actually lets an attacker do
Langflow exposes an OpenAI-style responses endpoint at /api/v1/responses. You call it with a model name and an input, and it runs the matching flow. The problem is how the backend resolves that model name into a flow. The helper get_flow_by_id_or_endpoint_name accepts either a friendly endpoint name or a raw flow ID. When the value parses as a UUID, the function fetches that flow straight from the database and never checks whether the caller owns it. Pass a name instead and the ownership check is applied. Pass an ID and it is skipped.
That asymmetry is the whole bug. An attacker with an ordinary account sends a POST to the responses endpoint, drops a flow ID they do not own into the field where the model name belongs, and signs the call with their own key. The server returns a 200 and runs the victim's flow. From the advisory's own breakdown, that means the attacker can execute any flow on the box, read data those flows process, and burn the victim's model and cloud quota in the process. The score sits at 9.9 rather than lower because the impact crosses a trust boundary: the request comes from the attacker's account, but the work happens under the victim's flow, with the victim's connected systems in scope.
Why "authenticated" is not the comfort it sounds like
It is tempting to file this under low risk because the attacker needs an account. On a single-user laptop install, that reasoning holds. On anything shared, it falls apart fast. Langflow is built to be multi-tenant, and the way people actually deploy it, a team instance, a department's internal AI platform, a hosted sandbox for clients, is exactly the configuration where one tenant running another tenant's flow is a real breach.
The reason the stakes are high is what lives inside a flow. Langflow is an open-source tool for assembling AI applications visually, and it is widely deployed: the project has more than 145,000 stars on GitHub. Instances are routinely set up with credentials for model providers such as OpenAI and Anthropic, for cloud platforms, and for live databases, because that is what makes the flows do anything. Running someone else's flow is a way to use those credentials without ever seeing them. We have written before about attackers going after the API keys baked into developer tools, and the logic here is the same: the credential is the prize, and you do not need to exfiltrate it if you can make the victim's own code spend it for you.
The pattern: Langflow keeps failing the same authorization check
Here is the claim worth holding onto. CVE-2026-55255 is not an isolated slip. It is the latest entry in a 2026 string of missing-ownership bugs across Langflow's API, and they all rhyme.
- CVE-2026-34046: a missing ownership check on the flow endpoints let any authenticated user read, modify, and delete any flow.
- CVE-2026-33760: the monitoring API exposed seven endpoints that read and wrote other users' messages and sessions with no ownership enforcement.
- CVE-2026-55255: the same missing check, now on the responses endpoint, turning a data-access bug into a code-execution one.
Three different routes, one root cause: the code authenticates who you are but forgets to verify what you are allowed to touch. This class has a name, broken object-level authorization, and it is the kind of flaw that does not get fixed once. It gets fixed one endpoint at a time, which is why a project can patch it in March and ship it again in June. The fix for CVE-2026-55255 normalizes the user ID and enforces the ownership check on both the ID and the name path, returning a 404 for cross-user access. That is the correct fix for this endpoint. It does nothing for the next endpoint that forgot.
The reason to take Langflow's authorization debt seriously is that attackers already have. Earlier in 2026, an unauthenticated remote code execution bug in Langflow, CVE-2026-33017, went from advisory to in-the-wild exploitation in roughly 20 hours, according to Sysdig's threat research team. That one needed no account at all. CVE-2026-55255 does need an account, which buys some time, but a tool with that exploitation history and that much sensitive material inside it is not one to leave a quarter behind on patches.
What to do now
Upgrade to Langflow 1.9.1 or later. Worth knowing: the fix merged on April 22 and shipped in 1.9.1, but the public advisory did not land until June 19. If you track Langflow security by watching for advisories, you were exposed for two months while the patch sat in a release you may have skipped. Check your actual running version, not your last upgrade date.
For anyone running Langflow as a shared service, two more moves. First, do not treat the application's own login as your only boundary. Put a multi-tenant Langflow instance behind network segmentation so a compromised or hostile account is contained, the same way you would for any app whose authorization can fail open on a single missed check. Second, watch the responses endpoint. Cross-user flow execution shows up as one account driving flow IDs it has never created or edited, so a request to /api/v1/responses whose model value is a flow that account does not own is a clean signal to alert on. You own that telemetry even when the vendor's authorization does not hold.
The one-CVE takeaway is easy: patch to 1.9.1. The standing one is harder. A platform that has shipped this same authorization gap at three different endpoints in a single year is telling you where its next bug will be. If Langflow is in your stack, the safe assumption is that the application's access control is not load-bearing on its own, and you should build the boundary you actually trust around it.