CISA Adds Critical Langflow RCE to KEV Catalog, Orders Federal Agencies to Patch by April 8
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added a critical Langflow vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, signaling confirmed in-the-wild exploitation and sharply raising the priority for organizations using the popular AI workflow platform.
The flaw, tracked as CVE-2026-33017, affects Langflow versions before 1.9.0 and allows unauthenticated remote code execution. Under Binding Operational Directive 22-01, Federal Civilian Executive Branch agencies have until April 8, 2026 to apply fixes or otherwise mitigate the risk. Private-sector organizations are not bound by the directive, but CISA’s KEV inclusion is a strong warning that attackers are already abusing the bug in real environments.
The bug sits in the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint, which is intentionally designed to allow public flow building without authentication. The problem is that when an optional data parameter is supplied, the endpoint uses attacker-controlled flow data instead of the saved flow definition from the database. That malicious flow data can include arbitrary Python code in node definitions, which is then passed to exec() with no sandboxing, turning a public build feature into a direct unauthenticated RCE path.
In practical terms, that means a remote attacker can send a crafted HTTP request and execute arbitrary code on the server without credentials. For exposed Langflow deployments, the likely outcome is full system compromise rather than a limited application-layer issue. Once code execution is achieved, attackers can potentially steal secrets, pivot deeper into internal environments, tamper with workflows, or use the server as a foothold for broader cloud or data access.
The advisory makes clear that this is distinct from the earlier Langflow bug CVE-2025-3248, which CISA added to the KEV catalog in May 2025. That earlier flaw affected the /api/v1/validate/code endpoint and allowed unauthenticated code injection in versions prior to 1.3.0. Horizon3.ai, which discovered CVE-2025-3248, described it as easily exploitable and capable of giving attackers full control of vulnerable servers.
The newer issue is arguably more troubling from a design perspective because it exists in an endpoint meant to be unauthenticated by design for public flows. In other words, the problem was not simply missing authentication on an admin-style endpoint. It was the acceptance of attacker-supplied flow data containing executable Python code in a feature that already assumed public accessibility. That kind of bug is especially dangerous because it can survive earlier remediation efforts aimed at adjacent code paths.
Researchers and defenders have been warning that Langflow represents an increasingly important class of target: AI development and orchestration platforms that sit close to data sources, cloud credentials, internal APIs, and model pipelines. A critical RCE in that layer is not just another web app bug. In many environments, it can expose the connective tissue between models, secrets, automation logic, and enterprise data.
Recent reporting indicates attackers moved quickly. Security researchers observed exploitation attempts targeting CVE-2026-33017 shortly after disclosure, reinforcing a now-familiar pattern in which critical flaws in widely deployed open-source infrastructure are weaponized before many defenders finish patch validation. For internet-exposed AI tooling, the patch window is shrinking to hours rather than days.
The bigger lesson here is that agentic AI infrastructure is rapidly becoming part of the mainstream attack surface. Tools like Langflow are attractive because they are powerful, flexible, and often deployed quickly in labs, pilot projects, internal developer environments, and customer-facing prototypes. That mix of high privilege, fast adoption, and inconsistent hardening makes them ideal targets for opportunistic exploitation.
Organizations using Langflow should immediately identify exposed instances, upgrade to a fixed release, and review logs for suspicious POST requests to the vulnerable public build endpoint. They should also assume that recently exposed or unpatched servers may have been accessed, rotate secrets stored or reachable from those environments, and inspect for persistence or secondary payloads if compromise is suspected.
Reference Links and Sources
