When the KEV Item Is Your Agent Platform: CVE-2025-34291 and Langflow
A couple of weeks ago we walked through a 10.0 on a Thursday — a Cisco SD-WAN control-plane bug, a 72-hour KEV clock, and the shape of ConMon working under load. The vulnerable thing that week was infrastructure: a controller, a fabric, the plumbing underneath a service.
This time the vulnerable thing is the AI layer itself.
On May 21, CISA added CVE-2025-34291 to the Known Exploited Vulnerabilities catalog. It's a CVSS 9.4 (v4.0) account-takeover-to-remote-code-execution chain in Langflow — the popular open-source visual builder teams use to wire up multi-agent applications and chain LLM calls together. The federal remediation deadline under BOD 22-01 is June 4, fourteen days out. CrowdSec observed active exploitation in the wild starting back on January 23, several months before the KEV designation made it official.
We write a lot here about agentic risk in the abstract — the blast radius of an agent, non-human identity, data exfiltration through tool calls. This is the concrete version. It's worth being specific about what broke, because the specifics are the lesson.
The chain
The exploit isn't one bug. It's three ordinary web weaknesses that line up into something much worse than the sum:
- Permissive CORS. Langflow's default configuration allows cross-origin requests from any origin, with
allow_credentialsenabled. A page on an attacker's domain can talk to a Langflow instance using the victim's cookies. - No CSRF protection on token refresh. The refresh endpoint sets its cookie with
SameSite=None; Secureand has no CSRF defense. So a cross-origin request can carry the victim'srefresh_token_lfcookie and get back fresh access tokens. - A code-execution endpoint that works as designed.
/api/v1/validate/coderuns user-supplied Python throughexec(). That's not a bug — it's a feature of a tool whose whole job is to let you build and test workflow components.
Put them in order and the attack is almost boring to describe. A logged-in Langflow user visits a malicious webpage. The page makes a cross-origin POST to /api/v1/refresh using the cookie the browser helpfully attaches, reads the access token out of the response, and turns around and posts attacker-controlled Python to the code-validation endpoint. Now there's remote code execution on the Langflow host — and from there, decryption of every credential the platform had stored: API keys, database passwords, service tokens.
No phishing of a password. No malware on the victim's machine. One visited link.
Affected versions run through 1.6.9. The fix lands in 1.7; 1.6.0 and later expose CORS customization that lets you mitigate manually, but the defaults stayed vulnerable, which is why "we're on a recent version" wasn't enough on its own.
Why an orchestration tool is the worst place for this
The Cloud Security Alliance's note on this CVE put the reason plainly: AI orchestration platforms "accumulate high-value credentials by design." Their entire purpose is to sit as a trusted intermediary between model APIs and the enterprise data systems behind them. To do that job they hold the keys — to the model providers, to the vector stores, to the databases the agents read from and write to.
Stack arbitrary code execution on top of a credential vault and you've built, accidentally, the threat model of a privileged piece of infrastructure. The CSA's framing is one we'd echo: any platform that combines stored credentials with code execution deserves the same scrutiny you'd give a domain controller, not the lighter touch a "dev tool" or "internal experiment" usually gets.
That last part is where we see the gap most often. These platforms tend to arrive through the side door — a data scientist stands one up to prototype, it proves useful, it quietly accretes credentials and traffic, and nobody ever re-classified it from "experiment" to "production system holding the keys to everything." The inventory never caught up to the risk.
If you're inside a FedRAMP boundary
The mechanics from the Cisco post apply here too, so we won't repeat them at length — the ConMon walkthrough covers how a KEV item inherits its federal due date as your remediation deadline, overriding the standard 30/90/180-day windows. June 4 is the date that matters.
What's different is the question the clock asks. Last time it was "do we run this network device, and where?" This time it's harder, because AI orchestration tooling rarely shows up cleanly in a boundary diagram:
- Can your inventory even answer it? "Do we run Langflow — or anything like it — anywhere inside the authorization boundary, at what version, owned by whom?" If the honest answer is "we'd have to go ask around," the fourteen days are already shrinking.
- What does it have credentials to? An orchestration host under suspicion isn't just a patch target. Every secret it held should be treated as potentially exposed and rotated — the model API keys, the database passwords, the service tokens. RCE plus a credential store means the blast radius is everything it could reach, not just the box itself.
- Is it in the SSP at all? A platform that entered through prototyping and never got documented is a finding in two directions at once: the vulnerability, and the fact that an unrecorded system was sitting inside the boundary holding production credentials.
- What does the evidence trail look like? Same as ever — scan output before and after, the rotation tickets, the POA&M entry if you opened one, the notification if it rose to that level. The artifact that survives the next assessment is the trail, not the outcome.
What we keep coming back to
The unglamorous tooling we talked about last time is exactly what makes this one survivable: an inventory query that returns in seconds, a CVE feed wired to the asset list, standing evidence collection that captures the before-and-after on its own. None of that is specific to Langflow. In three weeks the actively-exploited thing will be something else.
The one piece this CVE adds to the list is a question worth asking before the next KEV item lands: which of your AI systems are quietly holding production credentials, and are they classified — inventoried, monitored, governed — like the privileged systems they actually are? The honest version of that answer is the difference between June 4 being a normal Tuesday and June 4 being a fire drill.
It's the shape of work we've been building the Novaprospect audit engine toward — infrastructure-native discovery that finds the system you forgot to write down, evidence collected as a normal byproduct, KEV feeds in the same triage queue as everything else. An orchestration platform that aggregates credentials by design is precisely the kind of thing that should never be able to hide from your own inventory.
Reference
- CISA KEV addition (May 21, 2026): cisa.gov/news-events/alerts/2026/05/21
- CISA Known Exploited Vulnerabilities Catalog: cisa.gov/known-exploited-vulnerabilities-catalog
- Obsidian Security technical analysis: obsidiansecurity.com
- Cloud Security Alliance research note: labs.cloudsecurityalliance.org
- Prior read on the KEV clock and ConMon: /blog/kev-cve-2026-20182-fedramp-conmon