Langflow IDOR Flaw Added to CISA KEV After Cross-Tenant RCE Exploitation

CISA added CVE-2026-55255 to its Known Exploited Vulnerabilities catalog on July 7, 2026, with a federal remediation deadline of July 28. The vulnerability is an insecure direct object reference in Langflow’s flow management API. Active exploitation was confirmed between June 22 and June 25, with a single threat actor observed enumerating flows and achieving remote code execution by running workflows that did not belong to their account.

This is the third Langflow vulnerability to appear on the KEV catalog since 2025. The pattern is consistent: Langflow’s exposed API surface, combined with its position as an orchestration layer for AI pipelines that often hold credentials and database connections, keeps it at the top of threat actors’ targeting lists.

What CVE-2026-55255 Actually Does

Langflow identifies flows by UUID. When a user makes an API request to read, modify, or execute a flow, the application is supposed to verify that the requesting user owns or has been granted access to that flow. The authorization check in affected versions failed to enforce this ownership constraint correctly.

An authenticated attacker on a shared Langflow instance could iterate or guess flow UUIDs and submit API requests against flows owned by other users. Because the server did not reject those requests based on ownership, the attacker could:

• Read the complete flow definition, including any embedded API keys, database connection strings, or system prompts
• Execute the flow and capture its output
• Modify the flow in place if the relevant endpoints also lacked the check

The RCE path follows naturally from execution. Langflow flows can run arbitrary Python code through custom components, make outbound HTTP requests, and invoke shell commands depending on the components configured. Running a victim’s flow in an attacker-controlled context, or inserting a malicious component into a victim’s flow, converts the IDOR into full code execution.

The Exploitation Window

CISA’s catalog entry indicates active exploitation was observed over a four-day window from June 22 to June 25, 2026. The actor described in reporting is characterized as a lone operator rather than a coordinated group. The exploitation behavior observed was:

1. Flow enumeration via sequential or semi-structured UUID requests
2. Identification of flows with active tool integrations or code-execution components
3. Execution of those flows to achieve RCE or to harvest embedded credentials

Langflow v1.9.1 was available before CISA’s KEV addition on July 7. The gap between patch availability and government action is consistent with the typical KEV notification timeline: exploitation observed, vendor patched, CISA confirms and catalogues.

Context: Langflow’s Recurring Vulnerability Problem

Three CVEs on CISA’s KEV catalog in roughly 14 months is a meaningful signal. The earlier Langflow entries:

CVE-2025-3248: Unauthenticated RCE via code injection in the /api/v1/validate/code endpoint. Exploited for cryptomining and, per Sysdig research published in July 2026, as the entry point for the JADEPUFFER agentic ransomware campaign that demonstrated fully autonomous AI-driven database extortion.

CVE-2026-33017: An RCE exploited for Monero mining operations, confirmed by CISA and associated with the same pattern of exposed Langflow endpoints being swept by financially motivated actors.

CVE-2026-55255 differs from its predecessors in that it requires authentication. In practice that bar is low in any shared deployment where multiple users or teams operate on a common Langflow instance. Enterprise deployments using Langflow as a central orchestration layer may have dozens or hundreds of accounts, any one of which could leverage this vulnerability against the others.

Why Multi-Tenant Langflow Is Particularly Exposed

The risk is amplified by how Langflow is typically deployed in organizations that build heavily on it. Flows are not inert configurations. They carry live credentials: OpenAI API keys, Anthropic API keys, database URIs, webhook tokens, cloud provider credentials. In some deployment patterns, those credentials are embedded directly in the flow definition rather than referenced from a secrets manager.

An attacker who can read a victim’s flows using the IDOR collects whatever the flow was configured with. An attacker who can execute the flows has the same access as the flow’s intended operator. If the flow has read access to a production database, so does the attacker. If it has write access to an S3 bucket or can send outbound HTTP requests to an internal API, those capabilities are now the attacker’s to use.

This is the structural problem that makes AI pipeline vulnerabilities different from a typical web application bug. The data at risk is not just what’s stored in the application; it’s every credential and system the application was authorized to reach.

Defensive Guidance

Patch to v1.9.1 immediately. There is a fixed version and active exploitation is confirmed. This should not wait for a scheduled maintenance window.

Audit flow access logs. Review API request logs for the period June 22 to July 10 for anomalous flow access patterns: high volumes of flow GET requests, requests for flows not owned by the requesting account, or unusual flow execution events. Look specifically for enumeration sequences where a single account accessed many distinct flow UUIDs in rapid succession.

Remove credentials from flow definitions. API keys and database credentials embedded in flow YAML or JSON are now a known exfiltration target. Replace embedded credentials with references to environment variables or a secrets manager. Treat any embedded credentials from flows on instances running versions prior to v1.9.1 as potentially compromised.

Restrict network exposure. Langflow’s API should not be internet-accessible unless explicitly required. Place it behind a VPN or private network boundary. Require authentication on all API paths and ensure that the authentication layer is not bypassable at the proxy or load balancer level.

Audit Langflow deployments for users who should not have access. In shared deployments, review the user list and deactivate accounts that are no longer needed. Limit the number of users on shared instances where possible, and evaluate whether a per-team deployment model reduces the blast radius of any single account compromise.

For security teams monitoring for signs of exploitation: a POST request to a flow execution endpoint where the authenticated user does not own the target flow UUID is the primary indicator. Many log pipelines will not capture this distinction without custom flow ownership context, which means baseline detection requires correlating Langflow user IDs against flow ownership records from the application database.

References

• CISA Adds 4 Actively Exploited Adobe, Joomla, and Langflow Flaws to KEV (The Hacker News)
• CISA orders feds to prioritize patching Langflow auth bypass flaw (BleepingComputer)
• CISA Known Exploited Vulnerabilities Catalog
• Langflow v1.9.1 Release Notes