Four listings, one root cause
Langflow is a visual builder for AI agents and RAG pipelines. Between 2025 and 2026 it accumulated an unusual distinction: repeat entries in CISA's Known Exploited Vulnerabilities catalog. KEV is not a severity score — an entry means exploitation was observed in the wild.
- CVE-2025-3248 (CVSS 9.8, KEV 2025-05-05) — unauthenticated
exec()reachable on
/api/v1/validate/code. Code submitted for "validation" was executed before any authentication ran.
- CVE-2026-33017 (9.3) — unauthenticated RCE via
/api/v1/build_public_tmp/.../flow. - CVE-2025-34291 (9.4) — a CORS-plus-CSRF token chain ending in account takeover.
- CVE-2026-55255 — an IDOR on
/api/v1/responses: pass someone else's identifier, read their flows
and the secrets embedded in them.
Different endpoints, one shape. In each case a request reached privileged behaviour before the system established who was asking and whether they were allowed.
The ~20 hour number is the part to sit with
For CVE-2026-33017, attackers were exploiting in the field within roughly 20 hours of disclosure — before a public proof-of-concept existed. That collapses the mental model most patch processes are built on. "Patch within a week" assumes a lag between disclosure and weaponisation that no longer reliably exists for internet-reachable agent infrastructure. If your exposure window is measured in days, you were never actually protected by patch velocity; you were protected by not being noticed.
Why an agent framework is a worse thing to lose than an app
A typical web app breach leaks that app's data. An agent-building platform is a concentrated credential store: model API keys, cloud credentials, database connection strings, and the tool definitions describing exactly what each credential can reach — all colocated so that flows can use them.
So the blast radius is categorically different. One authorisation gap does not leak one secret; it leaks the ring, plus a map of what each key opens. The IDOR case makes this concrete: reading another tenant's flow returns their secrets as an ordinary property of the flow.
This is also why exploitation was commercial rather than opportunistic. The Flodrix botnet and a Sysdig-documented agentic-ransomware operator (JADEPUFFER) chained the IDOR with the RCE in June 2026 — harvest credentials, then use them. An agent platform is worth building tooling against.
What to actually do
- *Authenticate and authorise every flow and tool endpoint, deny-by-default.* Authentication alone
would not have stopped the IDOR: the caller was authenticated, just not checked against the object they named. Every identifier arriving from a client is a claim, not a fact.
- Do not expose an agent builder directly to the internet. Put it behind a VPN or identity-aware
proxy. Three of these four were unauthenticated paths; network reachability was the precondition.
- Scope secrets per tenant and per agent, with short lifetimes. The goal is that reading one flow
yields credentials that are narrow and expiring, not a master set.
- Treat any exposed instance as compromised even after patching. Patching closes the door; it does
not evict anyone already inside or rotate what they took. Rotate credentials and audit flow contents.
- Never pass client-supplied code to
exec()— but note that CVE-2025-3248 is the least
interesting of the four. The authorisation bugs are the durable lesson, because they look like ordinary application code rather than obvious footguns.
The transferable point
Agent frameworks tend to be adopted as developer tools and then quietly promoted to production infrastructure without the review that promotion normally triggers. The security posture stays that of a local prototyping utility while the credential concentration becomes that of a secrets manager. Harden them on the second basis, not the first.