CVE-2026-55255

What it actually does

CVE-2026-55255 is an authorization bypass in Langflow versions prior to 1.9.2. The /api/v1/responses endpoint accepts a user-supplied flow identifier without correctly verifying that the authenticated caller owns or is authorized to execute that flow. A low-privileged authenticated attacker can therefore invoke flows belonging to other users by submitting another user's flow ID. Because Langflow flows may contain AI agent logic, integrations, prompts, credentials, data retrieval steps, or external tool calls, successful exploitation can lead to unauthorized execution of workflows, exposure of sensitive flow outputs, modification of intended business logic through unintended execution paths, and potential downstream impact on connected systems.

Why it matters to the business

An attacker with any valid Langflow account can run other users' AI workflows without permission, potentially exposing sensitive responses, triggering unintended automations, consuming compute or API resources, and abusing integrations connected to those flows. The issue is listed in CISA KEV with active exploitation observed in the wild and a remediation due date of 2026-07-10, so organizations running affected Langflow deployments should treat remediation as urgent even though ransomware use has not been reported. Langflow's role in building AI agents and workflows increases operational risk because a single unauthorized flow execution may interact with external services, retrieve private data, or initiate automated actions.

How an attack unfolds

An attacker first obtains authenticated access to a Langflow instance, such as through a legitimate low-privilege account, compromised user credentials, or exposed registration. The attacker then discovers or guesses valid flow identifiers belonging to other users through UI leakage, API responses, shared links, logs, predictable identifiers, or prior access. The attacker sends a crafted request to /api/v1/responses and supplies the victim's flow ID. In vulnerable versions prior to 1.9.2, the server processes the request as long as the attacker is authenticated, but fails to enforce object-level authorization against the requested flow. The victim's flow is executed under conditions the attacker should not control, and the attacker may receive the generated response or cause connected integrations and tools within the flow to run. In active exploitation scenarios, attackers are likely to enumerate flow IDs, repeatedly invoke high-value flows, and search for outputs containing secrets, internal data, model prompts, retrieval results, or integration responses.

How to fix it

Upgrade Langflow to version 1.9.2 or later, which fixes the authorization flaw. If immediate upgrade is not possible, restrict access to Langflow to trusted networks or VPN users, disable public self-service registration, enforce strong authentication, and apply compensating controls at the reverse proxy or API gateway to limit access to /api/v1/responses. Review Langflow permissions and sharing settings, rotate credentials or API keys embedded in flows that may have been executed by unauthorized users, and invalidate active sessions where credential compromise is suspected. Because this vulnerability is in CISA KEV and actively exploited, prioritize remediation ahead of routine patch cycles and meet the 2026-07-10 KEV deadline where applicable.

How to confirm the fix worked

Confirm the deployed Langflow version is 1.9.2 or later using the application UI, package metadata, container image tag, or deployment manifest. Test authorization behavior with two separate non-admin accounts: create a flow as user A, authenticate as user B, and attempt to execute user A's flow through /api/v1/responses. A fixed deployment should deny the request with an authorization error and should not execute the flow. Review application and reverse-proxy logs to ensure requests to /api/v1/responses are associated only with flows owned by, shared with, or otherwise authorized for the requesting user. Validate that network restrictions, authentication controls, and rate limits are in place if the service remains exposed during patching.

Typical attack path

1. Authenticate to a vulnerable Langflow instance using any valid account or compromised credentials.
2. Identify candidate flow IDs belonging to other users through exposed API responses, UI artifacts, shared links, logs, predictable identifiers, or enumeration.
3. Send a crafted request to /api/v1/responses containing a flow ID owned by another user.
4. Abuse the missing object-level authorization check to execute the victim's flow.
5. Collect returned flow responses, sensitive data, prompts, or integration output, or trigger unintended downstream workflow actions.
6. Repeat against additional flow IDs to enumerate and execute other users' workflows.

How to detect it

To determine whether exploitation already occurred, review Langflow application logs, API audit logs, reverse-proxy logs, WAF logs, container logs, and identity-provider sign-in logs for access to /api/v1/responses before the upgrade to 1.9.2. Correlate each request's authenticated user with the flow ID submitted in the request and the legitimate owner or sharing permissions for that flow. Suspicious activity includes a user executing flows they do not own, repeated requests to different flow IDs, unusually high response endpoint volume, requests from new geographies or hosting providers, access shortly after account creation, and user agents or scripts not normally used by Langflow users. Where request bodies are logged, search for flow identifier fields submitted to /api/v1/responses and compare against ownership metadata. Investigate any returned responses that may have contained sensitive data, and examine downstream systems integrated with Langflow for actions triggered at the same timestamps. Because the vulnerability is reported as actively exploited in the wild, absence of errors is not sufficient; successful exploitation may appear as normal authenticated API traffic unless object ownership is checked during analysis.

• /api/v1/responses
• POST /api/v1/responses
• flow_id
• flowId
• responses endpoint
• Langflow

What your security team should do

• Immediately inventory all Langflow deployments, including containers, developer workstations, hosted instances, and AI workflow platforms embedding Langflow.
• Upgrade affected Langflow deployments to 1.9.2 or later as a priority because the vulnerability is in CISA KEV and active exploitation has been reported.
• Before patching is complete, restrict external access to Langflow and especially the /api/v1/responses endpoint using VPN, allowlists, reverse-proxy policy, or application gateway controls.
• Hunt for historical cross-user flow execution by correlating authenticated user IDs, requested flow IDs, flow owners, timestamps, source IPs, and response endpoint activity.
• Review flows for embedded credentials, API tokens, private prompts, sensitive retrieval sources, and external integrations; rotate secrets that could have been exposed or misused.
• Enable detailed API access logging for Langflow, including authenticated principal, requested endpoint, flow ID, source IP, user agent, status code, and request correlation ID.
• Monitor for high-volume or sequential access to /api/v1/responses, repeated authorization failures after patching, and access from unusual IP addresses or user agents.
• Ensure the KEV remediation deadline of 2026-07-10 is tracked through vulnerability management and exception processes.