CVE-2026-55255

Think of Langflow as a shared workspace where people can run their own AI workflows. This bug is like someone being able to guess (or obtain) another person’s workflow “ID” and then run it under their own login. If that other workflow uses private instructions or data, it could also expose that information or cause unwanted workflow activity.

This matters if your business uses Langflow and has any users who shouldn’t be trusted to access other people’s workflows. Because the flaw requires authentication and a victim’s flow ID, it’s most relevant when a user can log in and you have a realistic chance they could obtain or guess another flow’s ID. The reachability gate is: risk is present only if an attacker is authenticated and can supply a victim’s flow ID to /api/v1/responses.

This is a high-priority issue (Amber) because it allows authenticated cross-user access: attackers can run someone else’s flow by referencing their flow ID. There’s no public exploit code on record and CISA KEV doesn’t list it, but you should still upgrade promptly because the impact can include sensitive data exposure and unauthorized workflow execution.

Confirm exposure

• Identify the Langflow version you are running.
• Check whether it is older than 1.9.2 (the vulnerable range is “prior to 1.9.2”).

Upgrade remediation

• Upgrade Langflow to 1.9.2.
• If you use container images, update to the image/build that corresponds to Langflow 1.9.2.
• Note: upgrading should be straightforward, but you should follow your normal deployment process (staging first if you have one).

Target fixed versions

• langflow → fixed in 1.9.2.

Temporary workaround (if you can’t patch immediately)

• Reduce who can log in to Langflow: remove or lock down any accounts that shouldn’t have access to other users’ workflows.
• Avoid exposing /api/v1/responses to untrusted networks where possible (for example, limit access via internal network/VPN or strict firewall rules), so only trusted staff can reach it.

Verification after patch

• Using a test account, attempt to call /api/v1/responses with a flow ID that belongs to a different user.
• Confirm the API does not execute the other user’s flow and returns an authorization/ownership error instead.

What to monitor

• Look for unusual calls to /api/v1/responses from authenticated accounts that repeatedly reference many different flow IDs.
• Review application logs for authorization failures or “unexpected flow ownership” patterns after the upgrade.

Severity is effectively very high based on the described authorization bypass: CWE-639 (Insecure Direct Object Reference). Mechanism: the /api/v1/responses endpoint does not properly enforce that the flow ID provided by the caller belongs to the authenticated user, enabling authenticated cross-user flow execution.

Exploitation status: CISA KEV does not list this issue, and there is no public exploit code recorded. While there is EPSS prediction data, it is not treated as confirmation of real-world exploitation.

Fix: the vendor remediation indicates a patch was introduced with Langflow 1.9.2, including a referenced pull request and security advisory.

Attack vector: network-based API access with no user interaction required; the attacker must be authenticated and must know or obtain another user’s flow ID.