One visit to a malicious webpage. No credentials required from the attacker. No user interaction beyond that single click. The result: full account takeover and remote code execution on your Langflow instance, plus every API key, OAuth token, and database password the platform is holding on your behalf.
That is what CVE-2025-34291 does. CVSS 9.4. CISA added it to the Known Exploited Vulnerabilities catalog on May 21, 2026, with a federal remediation deadline of June 4. If you are running Langflow before version 1.7, read this before you open another browser tab.
Three misconfigurations, one catastrophic chain
Obsidian Security's write-up is precise on this: the vulnerability "did not stem from a single critical flaw but rather from the convergence of several individually minor configuration choices." That framing matters, because it explains why it slipped through.
The three components:
1. Overly permissive CORS. Langflow's default configuration allows cross-origin requests with credentials from any origin. That is the foundation everything else rests on.
2. SameSite=None refresh token cookie. The /api/v1/refresh endpoint uses a cookie configured as SameSite=None, which means the browser will send it with cross-origin requests. No additional CSRF protection exists on that endpoint.
3. A Python execution endpoint that works as designed. /api/v1/validate/code executes Python code. By design. That is how Langflow's visual workflow builder works — it validates node code by running it. There is nothing wrong with the endpoint in isolation. In combination with steps one and two, it becomes the payload delivery mechanism.
The full attack sequence: a logged-in Langflow user visits an attacker-controlled page. JavaScript on that page makes a cross-origin POST to /api/v1/refresh. The browser attaches the victim's cookie automatically — SameSite=None guarantees this. The attacker receives a valid access/refresh token pair. They then POST to /api/v1/validate/code with that token, pass arbitrary Python, and achieve RCE. The entire chain completes in one automated browser request cycle. The user notices nothing. The Langflow process keeps running.
Why this is not just another CORS bug
A kunnig läsare kan invända — and the objection is fair — that CORS misconfigurations are well-documented, low-hanging fruit, and have been patched in hundreds of applications before this one. The counter is that the damage profile here is categorically different.
Langflow is not a CRUD application that stores user records. It is an AI workflow orchestration platform. Teams wire it into their entire SaaS stack: OpenAI API keys, Anthropic credentials, database connection strings, OAuth tokens for Google Workspace, Slack webhooks, CRM integrations. Langflow stores these as global variables so workflows can use them without re-entering credentials each run.
That architecture makes a compromised Langflow instance a generalnyckeln — a master key — to everything connected to it. The CORS bug is the entry point. The credential store is the payload. One intrusion yields the access material for a dozen downstream services.
MuddyWater: the attribution caveat
In March 2026, Ctrl-Alt-Intel published analysis linking exploitation of CVE-2025-34291 to MuddyWater, an Iranian threat group assessed to be affiliated with Iran's Ministry of Intelligence and Security (MOIS). The group has been active since at least 2017 and has a documented history of targeting telecommunications, government, energy, and defence sectors.
Oasis Security independently documented a campaign with MuddyWater-consistent TTPs — specifically the ArenaC2 framework — that scanned more than 12,000 internet-exposed systems using at least five CVEs across multiple platforms. That campaign is associated with confirmed data theft from an Egyptian aviation organisation: approximately 200 files including passport records, payroll data, credit card information, and internal documents.
The attribution caveat is important. The link between MuddyWater and CVE-2025-34291 specifically rests on TTP-based inference: the actor scanned for the vulnerability and operational patterns match historical MuddyWater tradecraft. No publicly available forensic report confirms that the Egyptian airline compromise used Langflow as the entry point. The responsible read is: an actor with MuddyWater-consistent behaviour was actively weaponising this vulnerability for initial access. The forensic chain to a specific confirmed intrusion via Langflow specifically remains incomplete.
That distinction does not change the threat posture. It changes the confidence level of the attribution sentence you repeat to your management.
The AI dev tool in production gap
Langflow has over 140,000 GitHub stars. DataStax acquired it in 2024. IBM is currently in the process of acquiring DataStax. The platform is deployed — not just evaluated — in healthcare, financial services, and enterprise support automation.
The deployment pattern that creates the exposure: a team spins up Langflow on an internal port, wires in their credentials, builds workflows, and eventually opens access for more team members. The port ends up reachable from the office network, then from a VPN, then from a cloud VM with a broader exposure surface than originally intended. The security posture never catches up to the access model. Langflow was designed for development environments. It acquired production semantics while keeping development defaults.
Obsidian's analysis notes that 1-click RCE persists under default configuration up to version 1.7. That means the exposure is not a misconfiguration an administrator made — it is the out-of-box state.
Patching Langflow in production is harder than it looks on paper. If workflows are wired to specific API versions or model configurations, a version jump can break integrations. Teams running self-hosted Langflow without a dedicated maintainer may have no clear upgrade path documented. The DataStax/IBM acquisition transition creates uncertainty about which team owns the vulnerability response process going forward. These are real barriers, not excuses, and they explain why actively exploited CVEs in dev-tooling-turned-production-infrastructure tend to stay unpatched longer than CVEs in traditional enterprise software.
What version 1.7 changes
The patch implements secure defaults for CORS and cookie handling. Specifically: CORS is tightened to reject cross-origin credentialed requests by default, and the refresh token cookie gets a SameSite setting that prevents cross-origin attachment.
Update to Langflow 1.7 or later. That is the single required action. For teams that cannot update immediately, PR #10139 provides a manual CORS configuration path — restrict LANGFLOW_CORS_ORIGINS to explicit, trusted origins and disable SameSite=None on the refresh token cookie.
Exposure check: three questions
If you run Langflow, answer these before anything else:
Is your instance reachable from outside your local machine? Check what interface Langflow is bound to. If it is 0.0.0.0 and you have any network exposure broader than localhost, you are in scope.
What credentials does your Langflow instance hold? Open the global variables panel and list what is stored. Assume that if you are on an affected version and your instance has had network access, those credentials have been compromised.
When did you last check the version? The vulnerable range is everything before 1.7. If you are unsure, check the About page or the process metadata. Do not assume you are current because the install is "recent."
For organisations under FCEB scope: the CISA deadline is June 4. That applies to federal civilian executive branch agencies, not private sector, but it is a reasonable urgency benchmark regardless of sector.
The structural problem this points to
CVE-2025-34291 is the first well-documented case of a nation-state actor using an AI workflow orchestration tool as an initial access vector for a broader campaign. It will not be the last.
The broader pattern: the tools being adopted fastest in AI development pipelines — visual builders, orchestration platforms, local model servers — were designed to make capability accessible, not to be deployed in adversarial environments. When those tools end up holding API keys for an organisation's entire cloud stack, the security model needs to match the actual role the tool is playing, not the role it was designed for.
Treat your Langflow instance the way you would treat any backend service that holds credentials: dedicated host or isolated container, no direct internet exposure, reverse proxy with authentication in front, secrets in a dedicated vault rather than the application's native variable store. If those controls are not in place today, that is the configuration work that needs to happen alongside the version update — not instead of it.
Sources: Obsidian Security — CVE-2025-34291 technical analysis · CISA KEV catalog · Oasis Security — Iran-nexus campaign · The Hacker News — KEV listing · MITRE ATT&CK G0069 — MuddyWater