CISA: Langflow flaw is now actively exploited

CISA has added a new Langflow vulnerability to its Known Exploited Vulnerabilities catalog. The wording is technical. The operating lesson is not: tools used to build AI agents and automated workflows must be treated as critical infrastructure, not as harmless experiments in a developer lab.

The U.S. cybersecurity agency published the alert on May 21 and said CVE-2025-34291 was added to the KEV catalog based on evidence of active exploitation. CISA describes the issue as an origin validation error in Langflow. An overly permissive CORS configuration, combined with a refresh-token cookie configured as SameSite=None, can allow a malicious webpage to make cross-origin requests that include credentials. In the worst case, an attacker can obtain tokens, reach authenticated endpoints, execute code and achieve full system compromise.

Langflow is not a random package buried deep in an application. The project describes itself as a tool for building and deploying AI-powered agents and workflows. That puts the vulnerability in one of the fastest-growing enterprise categories: agent platforms, internal copilots, workflow builders and low-code automation tools connected to data, APIs, files and business processes. When these tools are exposed, the risk is not just another application bug. They can become a route into the agent operating environment itself.

CISA set a June 4, 2026 deadline for U.S. federal civilian agencies. BOD 22-01 formally applies to those agencies, but CISA also urges all organizations to prioritize timely remediation of KEV vulnerabilities as part of their vulnerability management practice. That is the part enterprise leaders outside the U.S. should care about. The KEV catalog is not an academic CVE list. It is a list of vulnerabilities where there is evidence of real-world exploitation.

The NVD record makes the risk more concrete. It points to Langflow versions up to and including 1.6.9 and describes a chained vulnerability that can enable account takeover and remote code execution. NVD lists a CVSS 4.0 score of 9.4 from VulnCheck and a CVSS 3.1 score of 8.8 from NVD. Langflow’s GitHub release for version 1.9.3, published on May 15, is described as a critical security release and recommends immediate upgrading. The release notes mention SSRF protection, CVE fixes and updated security dependencies.

The leadership point is not that every company uses Langflow. The point is that agent tooling is often introduced without the same discipline applied to established business systems. It may sit inside developer environments, data science teams, innovation labs and product groups. It may be connected to model APIs, internal documents, databases, CRM systems, ticketing, GitHub, Slack and cloud resources. Then the question is no longer whether the tool works. The question is who owns it, who patches it, which credentials it holds and what a compromise would actually allow.

This is also a signal of how quickly the AI stack’s risk profile is changing. Many organizations have decent visibility over ERP systems, email, identity, endpoint and classic servers. Fewer have the same visibility over agent prototypes, MCP servers, workflow builders and open-source tools installed to test an idea. Yet these are exactly the components receiving more access. An agent that only reads demo data is one thing. An agent platform with tokens to internal systems, code repositories, customer data or production infrastructure is something else entirely.

For CIOs and CISOs, this should trigger four direct questions. First: do we run Langflow or similar agent builders anywhere, including test environments and local containers? Second: are these tools covered by vulnerability scanning, SBOM inventory and patch SLAs? Third: what tokens, secrets and system permissions are stored or reachable from the agent platform? Fourth: can we detect abnormal token use, workflow changes and agent calls outside expected behavior?

It is tempting to treat this as a simple patch story. That is too narrow. The bigger governance message is that AI-agent environments must be brought into the same operating model as other production systems. That means inventory, version control, ownership, access control, hardening, network boundaries, secrets management, logging, backup, rollback and incident handling. If a tool can execute code, obtain tokens or orchestrate actions across systems, it is no longer a toy.

Boards do not need to memorize the CVE number. They need to know whether the organization has control over new technology surfaces that receive real operational power before they receive real governance. The Langflow case is a concrete reminder. AI agents are not only a productivity category. They are a new attack surface.

The practical recommendation is blunt. Find internal Langflow installations and equivalent agent builders. Patch or isolate them. Rotate tokens if there is any sign of exposure. Remove broad service accounts. Set explicit boundaries for which systems agent tools can reach. And make KEV vulnerabilities a leadership-reported patch category, not a backlog item that disappears between sprints.

Sources and media

Primary source: CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog", published May 21, 2026: https://www.cisa.gov/news-events/alerts/2026/05/21/cisa-adds-two-known-exploited-vulnerabilities-catalog

CISA KEV catalog: CVE-2025-34291 Langflow Origin Validation Error Vulnerability, added May 21, 2026, due June 4, 2026.

NVD: CVE-2025-34291, Langflow versions up to and including 1.6.9, CVSS data and technical description: https://nvd.nist.gov/vuln/detail/CVE-2025-34291

Langflow GitHub: project description and the v1.9.3 security release from May 15, 2026: https://github.com/langflow-ai/langflow/releases/tag/v1.9.3

Thumbnail: OpenAI Image 2 / hogby.ai.