Zerodayhub

TL;DR: CVE-2026-55255 is a critical (CVSS 9.9) authorisation bypass in Langflow, the popular open-source framework for building AI agents and RAG pipelines. A logged-in attacker can hijack and execute any other user’s workflow – and the credentials embedded in it – just by guessing its ID. It’s fixed in Langflow 1.9.1, it’s on CISA’s Known Exploited Vulnerabilities catalogue, and if you’re running a multi-tenant Langflow instance you should already have patched.

Key takeaways

• CVE-2026-55255 is an Insecure Direct Object Reference (IDOR) in Langflow’s /api/v1/responses endpoint, scoring 9.9 (Critical) under CVSS 3.1.
• Any authenticated user – even a low-privilege one – can execute another user’s AI workflow by submitting that workflow’s ID, with no ownership check performed.
• Hijacked workflows can leak the API keys, LLM provider credentials and cloud secrets embedded in their configuration, and consume the victim’s compute quota.
• Sysdig’s Threat Research Team observed the flaw being exploited in the wild on 25 June 2026; CISA added it to the KEV catalogue on 7 July 2026 with a 10 July deadline for US federal agencies.
• The fix is Langflow 1.9.1. If you can’t upgrade immediately, restrict network access to your instance and audit who can reach /api/v1/responses.

What is CVE-2026-55255?

CVE-2026-55255 is an Insecure Direct Object Reference (IDOR) vulnerability in Langflow, an open-source visual framework used to build and deploy AI agents and retrieval-augmented generation (RAG) pipelines. It carries a CVSS 3.1 base score of 9.9 – Critical – and is tracked under CWE-639, Authorization Bypass Through User-Controlled Key.

The flaw sits in Langflow’s /api/v1/responses endpoint, an OpenAI-Responses-compatible API where the model field is actually a flow’s UUID. When a flow is looked up by that UUID, Langflow’s backend queried the database for the flow directly, without ever checking whether the requesting user owned it. Any authenticated account on the instance – regardless of how low its privileges – could therefore trigger execution of a flow belonging to somebody else, simply by supplying that flow’s ID.

The bug was reported responsibly, published to the GitHub Security Advisory database (GHSA-qrpv-q767-xqq2) on 19 June 2026, and fixed in Langflow 1.9.1 via pull request #12832. It is one of several Langflow vulnerabilities to draw attention this year, following an earlier missing-authentication flaw (CVE-2025-3248) exploited by ransomware operators, and a separate unauthenticated remote-code-execution bug (CVE-2026-33017, CVSS 9.3) that has been mass-exploited since March 2026.

How the Langflow exploit works

In plain terms: Langflow lets each user save “flows” – visual pipelines that chain together LLM calls, tools and data sources – and run them through a REST API. Because of the flawed lookup, one user’s login could be used to run anyone’s flow, complete with whatever credentials and permissions that flow was built with.

The technical root cause lives in the get_flow_by_id_or_endpoint_name helper function. When a flow was requested by its human-readable endpoint name, the code correctly checked that the requester owned it. But when a flow was requested by its raw UUID – the format used by the /api/v1/responses endpoint – that ownership check was skipped entirely:

# ILLUSTRATIVE ONLY — mechanism, not a working exploit
async def get_flow_by_id_or_endpoint_name(flow_id_or_name, user_id=None):
    if is_uuid(flow_id_or_name):
        flow = db.get(Flow, flow_id_or_name)      # no ownership check performed
    else:
        flow = db.query(Flow).filter(
            Flow.endpoint_name == flow_id_or_name,
            Flow.user_id == user_id                # ownership check only happens here
        ).first()
    return flow

Exploitation requires the attacker to already hold valid credentials for the target Langflow instance (the vulnerability is not unauthenticated), and to know – or discover – a victim’s flow UUID. Because UUIDs are 122-bit random values, they can’t be brute-forced. In the exploitation Sysdig’s Threat Research Team documented, the attacker first called Langflow’s flow-listing endpoint to harvest a list of valid flow IDs, then replayed one of those IDs as the model parameter against /api/v1/responses, with an injected prompt designed to make the hijacked flow leak the API keys embedded in its own configuration.

A successful request lets the attacker execute the victim’s flow, view whatever it returns, and drain the compute and third-party credentials (OpenAI, Anthropic, cloud provider keys, database secrets) that Langflow flows commonly carry inline. On a single self-hosted instance, this is broadly equivalent to what the separate, higher-prevalence RCE bug (CVE-2026-33017) can already achieve – but on multi-tenant or managed Langflow deployments where code execution is sandboxed per customer, this IDOR is the one bug that reaches straight across the tenant boundary at the application layer.

The fix, released in Langflow 1.9.1, applies the ownership check to both lookup paths and returns a uniform 404 for cross-user requests, so an attacker can no longer even tell whether a given flow ID exists.

Is CVE-2026-55255 actively exploited?

Yes. Sysdig’s Threat Research Team observed the first confirmed in-the-wild exploitation on 25 June 2026, when a single opportunistic operator ran the IDOR against an internet-exposed Langflow instance in the same session as attacks against the unrelated Langflow RCE bug (CVE-2026-33017). The operator enumerated the instance’s flow list, replayed a harvested flow ID against /api/v1/responses with a prompt designed to leak API keys, and separately deployed a loader/dropper payload via the RCE flaw – indicative of low-sophistication, financially motivated, opportunistic tooling rather than a targeted campaign.

CISA added CVE-2026-55255 to its Known Exploited Vulnerabilities (KEV) catalogue on 7 July 2026, giving US Federal Civilian Executive Branch agencies until 10 July 2026 to remediate under Binding Operational Directive 26-04. A proof-of-concept curl request is published alongside the GitHub Security Advisory, so working exploitation details are public.

Researchers have noted that this IDOR has, so far, seen far less real-world exploitation volume than its lower-scored sibling RCE – because it requires valid credentials and a disclosed flow ID, whereas the RCE is unauthenticated and internet-sprayable. That doesn’t reduce its severity on multi-tenant or managed Langflow deployments, where it remains the most direct route to another customer’s data and secrets.

How to fix CVE-2026-55255: remediation & mitigation

Patch: Upgrade Langflow to version 1.9.1 or later. This is the only complete fix, closing the ownership check gap on both the UUID and endpoint-name lookup paths.

If you can’t patch immediately:

• Restrict network access to your Langflow instance to trusted users and internal networks only – don’t expose the API directly to the internet.
• Add access controls or a reverse-proxy rule in front of /api/v1/responses and /api/v2/workflow to limit who can reach them.
• Audit which accounts have been created on the instance and disable any you don’t recognise.

After patching:

• Rotate any API keys, LLM provider credentials, and cloud secrets that were embedded in Langflow flow configurations, since they may have been exposed even before the patch was applied.
• Review Langflow access logs for POST /api/v1/responses requests referencing flow IDs that don’t belong to the requesting account, and for prior calls to the flow-listing endpoint from unfamiliar accounts or IPs.
• Terminate active sessions for any account you suspect may have been compromised or misused.

Detection / IOCs: Look for enumeration of your flow-listing endpoint followed shortly afterwards by /api/v1/responses calls using a model value that doesn’t match the requesting user’s own flows. Sysdig’s public write-up on the first observed exploitation lists a source IP and loader URL associated with the broader campaign; treat these as indicators for that specific opportunistic operator rather than as exhaustive IOCs for the vulnerability class as a whole.

Frequently asked questions

Is CVE-2026-55255 an unauthenticated vulnerability?
No. Exploitation requires the attacker to already hold valid credentials for the target Langflow instance. The severity comes from the fact that any authenticated account – however low-privileged – can reach any other user’s flow, not from unauthenticated access.

Does this affect Langflow Cloud or only self-hosted instances?
The vulnerability affects any Langflow deployment running a version prior to 1.9.1, whether self-hosted or multi-tenant. It’s most severe on multi-tenant and managed deployments, where it’s the one flaw in the current Langflow vulnerability set that crosses the tenant boundary at the application layer rather than requiring a sandbox escape.

What’s the difference between CVE-2026-55255 and CVE-2026-33017?
CVE-2026-33017 is a separate, unauthenticated remote-code-execution vulnerability in Langflow (CVSS 9.3) that has been mass-exploited since March 2026. CVE-2026-55255 is the authorisation-bypass (IDOR) bug covered in this article. Researchers have observed the same opportunistic threat actors exploiting both in the same attack sessions, but they are distinct flaws with distinct fixes.

How do I know if I’ve already been targeted?
Check your Langflow logs for calls to the flow-listing endpoint followed by /api/v1/responses requests using flow IDs unrelated to the calling account, and for any signs of the loader/dropper activity associated with parallel exploitation of CVE-2026-33017 on the same host.

Sources & further reading

• GitHub Security Advisory GHSA-qrpv-q767-xqq2 – official vulnerability disclosure, technical detail and patch reference
• Sysdig Threat Research Team: Understanding Langflow CVE-2026-55255 – first documented in-the-wild exploitation analysis
• BleepingComputer: CISA orders feds to prioritize patching Langflow auth bypass flaw – CISA KEV addition and deadline coverage
• CISA Known Exploited Vulnerabilities Catalog – official KEV entry and BOD 26-04 guidance

ZeroDayHub tracks critical vulnerabilities as they break. Subscribe for updates.