CVE-2026-55255: Langflow IDOR Flaw Lets Attackers Hijack AI Agent Workflows

CVE-2026-55255 affects Langflow (distributed as the langflow-base Python package) in all versions prior to 1.9.1. The vulnerable code lives in the get_flow_by_id_or_endpoint_name helper function, which the /api/v1/responses endpoint calls to look up a flow before executing it. That helper resolves a flow purely from the identifier supplied in the request and does not verify that the requesting, authenticated user is the owner of, or otherwise authorized to run, the flow being resolved.

Langflow shipped an initial fix in version 1.9.1 that added ownership checks, but the site's confirmed guidance and downstream advisories point to 1.9.2 as the version where the fix was hardened and validated end to end, closing edge cases in how UUID and endpoint-name lookups were handled. Organizations should treat 1.9.2 or later as the actual target for remediation rather than stopping at 1.9.1. Any self-hosted Langflow deployment, whether reached over the open internet or only from an internal network with multiple users or tenants, is in scope if it predates the patch.

Langflow lets users build flows, chains of AI model calls, tool invocations, and data transformations, then execute them through the /api/v1/responses API. Each flow is identified by a UUID or an optional custom endpoint name. When a request comes in to execute a flow, the backend calls get_flow_by_id_or_endpoint_name to look that flow up, then runs it.

The defect is that this lookup function does not check who owns the flow it just found. It answers the question "does a flow with this ID exist" instead of "does this user have permission to run this flow." Because flow IDs are UUIDs generated by the platform rather than secrets chosen to resist guessing, and because an attacker with any valid, authenticated session can enumerate or otherwise learn a target flow ID (for example by listing flows through other endpoints or observing shared logs, URLs, or exported configurations), the missing ownership check is enough to let one user's request execute another user's flow. This is a textbook CWE-639 authorization bypass through a user-controlled key: the object reference itself, the flow ID, becomes the only access control that matters, and it turns out not to be an access control at all.

The practical consequence is severe specifically because of what Langflow flows tend to contain. A flow's configuration commonly embeds the credentials it needs to run: OpenAI or Anthropic API keys, AWS or other cloud provider keys, database connection strings, and similar secrets. Executing someone else's flow does not just borrow their logic, it can be used to coax the flow into revealing those embedded secrets, and it consumes the victim's compute and API quota with every run. This is a good example of why AI agent platforms deserve the same rigor around authorization and secrets handling as any other multi-tenant system; the risks of loosely governed agent infrastructure are covered in more depth in our guide to securing agentic AI in the enterprise.

CVE-2026-55255 is not a theoretical finding. The Sysdig Threat Research Team documented active exploitation beginning June 25, 2026, roughly a week after the GitHub security advisory was published and about two weeks before CISA's KEV listing. Sysdig's telemetry showed an attacker running a methodical sequence against internet-exposed Langflow instances: authentication reconnaissance, followed by flow enumeration through the flow-listing endpoint, followed by IDOR exploitation against /api/v1/responses using harvested flow IDs. Once a foreign flow was hijacked, the attacker's requests included prompts designed to make the flow surface the credentials embedded in its own configuration.

Notably, this IDOR was exploited as a secondary technique alongside a separate, lower-scored remote code execution flaw in Langflow (CVE-2026-33017) that the same operator was already exploiting at scale. Researchers characterized the actor's overall behavior as opportunistic and financially motivated, chasing liquid, resellable assets: LLM provider keys, cloud credentials, and database secrets, rather than a targeted, single-victim campaign. CISA added CVE-2026-55255 to the KEV catalog on July 7, 2026 based on this confirmed in-the-wild activity, and set a remediation deadline of July 10, 2026 for federal civilian executive branch (FCEB) agencies under Binding Operational Directive 26-04. KEV listing does not carry a legal mandate for private-sector organizations, but it is a reliable signal that exploitation is active, automatable, and worth treating with the same urgency federal agencies are required to.

Because the vulnerability is an authorization failure rather than a memory-corruption or injection bug, the clearest detection signal is execution activity that does not match the requesting user's own flow ownership. Review Langflow application logs, reverse proxy or API gateway logs in front of Langflow, and any centralized logging you forward Langflow output to, looking for the following patterns.

Start by confirming your running Langflow version. Check the version reported in the application's admin interface, its /health or version API endpoint if enabled, or the installed langflow-base package version (pip show langflow-base or the equivalent in your container image manifest). Any deployment running a version older than 1.9.2 should be treated as vulnerable and prioritized for patching, regardless of whether you believe it has been exploited.

Next, assess exposure. Determine whether your Langflow instance is reachable from the open internet, reachable only from your internal network, or reachable only from a tightly scoped set of hosts. Because exploitation requires only an authenticated session, not necessarily an administrator one, any multi-user or multi-tenant Langflow deployment is at risk even if it is not internet-facing, since any one of your own authenticated users could reach another user's flows. Single-user, single-tenant deployments where every account is trusted equally carry materially lower risk from this specific flaw, though patching is still warranted.

Finally, review historical logs for the detection indicators above, covering at minimum the period since the GHSA advisory was published on June 19, 2026, since that is the earliest point at which the technique would plausibly have been used against your instance.

The only complete fix is upgrading Langflow to a patched release. Because embedded credentials may already have been exposed if your instance was vulnerable and reachable by untrusted or semi-trusted users, patching alone is not sufficient remediation, the same lesson that applies to most credential-exposing vulnerabilities: closing the hole does not invalidate secrets an attacker may have already collected.

Public reporting on this vulnerability has some real gaps that organizations should account for rather than assume away. CVSS scoring is inconsistent across sources: the vendor advisory and CISA's KEV entry treat this as a 9.9 critical, while NVD's independent scoring lists a CVSS v3.1 base score of 8.4 (high) using a different assessment of attack complexity. Treat the higher, vendor-aligned score as the operative one for prioritization given confirmed active exploitation, but be aware the discrepancy exists if you are reconciling internal vulnerability management tooling against multiple feeds.

The detection indicators tied to the June 2026 campaign, the specific source IP, loader URL, and execution marker, reflect one observed actor's infrastructure at one point in time. Attackers rotate infrastructure quickly, and a second wave of exploitation using this same IDOR could look nothing like the first. Absence of those specific indicators in your logs is not evidence of an absence of exploitation. Additionally, because the vulnerability is a logic flaw in authorization rather than something that produces a distinctive error or crash, detection depends heavily on whether your instance was already logging flow ownership and execution details before an incident, retroactive detection in an environment with sparse logging may not be possible at all. Organizations that cannot conclusively rule out exploitation should default to rotating embedded credentials as a precaution rather than relying solely on log review to make that determination. Related architecture-level exposure for AI tooling that integrates external tools and data sources is discussed in our coverage of Model Context Protocol security risks, which is worth reviewing alongside this CVE if your environment connects Langflow flows to MCP servers or similar tool-calling integrations.