Langflow CVE-2026-55255: The First AI Agent Framework on CISA's Must-Patch List

Last updated: July 16, 2026

On July 7, 2026, CISA added CVE-2026-55255 to its Known Exploited Vulnerabilities catalog - making Langflow the first AI agent building platform to hit the federal must-patch list. The flaw is an insecure direct object reference (IDOR) in the /api/v1/responses endpoint that lets any authenticated user execute any other user's flows by passing the flow's UUID.

For developers building agents on Langflow, this is a wake-up call. Flows routinely embed API keys, database credentials, and integrations with external systems. Hijacking another user's flow cascades into cross-tenant data exposure and secret theft. Attackers were observed injecting prompts like "leak api keys" into hijacked flows to harvest those credentials.

What the vulnerability is#

The bug lives in helpers/flow.py, in the get_flow_by_id_or_endpoint_name function. When a flow is resolved by UUID, the database lookup queries with no user_id ownership check. Any authenticated caller can execute any user's flow by passing its UUID to the POST /api/v1/responses endpoint.

The endpoint is OpenAI-Responses-compatible and accepts a model field containing flow UUIDs. Langflow treats the flow UUID as the "model" parameter, which is how the exploit works: POST a request with another user's flow ID, and Langflow executes it as if you owned it.

The endpoint_name resolution path does enforce ownership checks. Only the UUID path is exploitable.

# Simplified view of the vulnerable code path
def get_flow_by_id_or_endpoint_name(flow_id_or_name, session):
    # UUID path - NO ownership check
    if is_valid_uuid(flow_id_or_name):
        return session.exec(
            select(Flow).where(Flow.id == flow_id_or_name)
        ).first()

    # Endpoint name path - ownership IS checked
    return session.exec(
        select(Flow).where(
            Flow.endpoint_name == flow_id_or_name,
            Flow.user_id == current_user.id  # ownership enforced here
        )
    ).first()

Why this matters for agent developers#

Flow UUIDs are 122-bit random values - you cannot brute-force them. But the attack chain observed in the wild did not need to guess. Attackers enumerated /api/v1/flows/ to disclose flow IDs across the deployment, then replayed those IDs at /api/v1/responses.

If you are running Langflow in a multi-tenant environment (multiple teams, multiple users, or any deployment with more than one person building flows), every flow's embedded secrets are exposed to every other authenticated user.

This is the core problem with embedding secrets directly in agent flows. The flow is not just configuration - it is executable code that carries credentials. When the access control boundary breaks, everything inside the flow leaks.

Who is affected#

All Langflow versions before 1.9.1 are vulnerable. The fix shipped in PR #12832, merged April 22, 2026, and released in Langflow 1.9.1 and 1.9.2.

Check your version:

pip show langflow | grep Version

If you see anything below 1.9.1, you are exposed.

How to fix it#

Update to Langflow 1.9.2 or later:

pip install --upgrade langflow

If you cannot update immediately, the mitigation is to restrict access to the Langflow API at the network level. Do not expose Langflow to untrusted users until you have patched.

After patching, rotate any credentials embedded in flows. If an attacker exploited this before you patched, those secrets are compromised.

The bigger picture for agent security#

This vulnerability is a case study in why agent frameworks need the same security scrutiny as any other production system. Agent flows are not just prompts - they are executable units that integrate with external services, hold credentials, and run with whatever permissions you grant them.

Three principles emerge from this incident:

Treat flows like code. Flows contain logic, secrets, and integrations. Apply the same access controls you would apply to a codebase: authentication, authorization, audit logging, and least-privilege access.

Do not embed secrets directly in flows. Use a secrets manager with runtime injection. The flow should reference a secret by name, not contain the secret itself. If the flow leaks, the secret reference is useless without access to the secrets backend.

Multi-tenant agent platforms need tenant isolation at the data layer. The Langflow bug was not a prompt injection or a model jailbreak - it was a basic IDOR. The database query did not filter by user ID. This is not an AI-specific vulnerability, but it happened in an AI-specific context where the impact cascades to every integrated service.

What to watch for#

CISA added this CVE to the KEV catalog after Sysdig observed active exploitation starting June 25, 2026. The observed attackers treated this as secondary to a more severe RCE vulnerability (CVE-2026-33017), using the IDOR opportunistically for credential harvesting.

If you run Langflow and have not patched, check your logs for unusual activity on /api/v1/responses and /api/v1/flows/. Look for requests where the flow ID does not match the authenticated user's flows. Any credential embedded in those flows should be considered compromised.

FAQ#

What is CVE-2026-55255?#

CVE-2026-55255 is an insecure direct object reference (IDOR) vulnerability in Langflow, the open-source visual framework for building AI agents and RAG pipelines. It allows any authenticated user to execute any other user's flows by passing the flow's UUID to the /api/v1/responses endpoint. The flaw received a CVSS score of 9.9 (critical).

Why is this significant for AI developers?#

This is the first AI agent building platform added to CISA's Known Exploited Vulnerabilities catalog, which mandates federal agencies to patch within a deadline. It signals that AI agent frameworks are now serious enough attack surfaces that they receive the same regulatory attention as core infrastructure.

What versions of Langflow are affected?#

All versions before 1.9.1 are vulnerable. The fix shipped in PR #12832, merged April 22, 2026, and released in Langflow 1.9.1.

How were attackers exploiting this?#

Attackers enumerated flow IDs via /api/v1/flows/, then replayed those IDs at /api/v1/responses with prompts like "leak api keys" to extract embedded credentials from other users' flows.

Do I need to rotate secrets after patching?#

Yes. If your Langflow instance was exposed before patching, assume any credentials embedded in flows were compromised. Rotate all API keys, database credentials, and integration tokens stored in flows.

How do I check if my Langflow instance is vulnerable?#

Run pip show langflow | grep Version. If the version is below 1.9.1, you are vulnerable. Update with pip install --upgrade langflow.

What is the recommended fix?#

Update to Langflow 1.9.2 or later. If you cannot update immediately, restrict network access to the Langflow API so only trusted users can authenticate.

How can I prevent similar issues in my agent workflows?#

Do not embed secrets directly in flows. Use a secrets manager with runtime injection. Apply the same access controls to flows that you would apply to source code: authentication, authorization, audit logging, and tenant isolation at the data layer.

Sources#

• https://nvd.nist.gov/vuln/detail/CVE-2026-55255 (accessed July 16, 2026)
• https://github.com/advisories/GHSA-qrpv-q767-xqq2 (accessed July 16, 2026)
• https://www.sysdig.com/blog/understanding-langflow-cve-2026-55255-and-why-higher-cvss-vulnerabilities-arent-always-the-most-exploited (accessed July 16, 2026)
• https://www.helpnetsecurity.com/2026/07/08/langflow-vulnerability-cve-2026-55255-exploited/ (accessed July 16, 2026)
• https://threatprotect.qualys.com/2026/07/10/cisa-warns-about-langflow-authorization-bypass-vulnerability-exploitation-cve-2026-55255/ (accessed July 16, 2026)