In July We Said Go Find Yours Before the Sixth. The Sixth Langflow KEV Landed August 4. Now MLflow Is on the List and the Prize Was Never the Model.
- Patrick Duggan
- 34 minutes ago
- 5 min read
On August 19 CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalog. The product is MLflow, the platform a very large number of teams use to track machine-learning experiments and register models. The flaw is a server-side request forgery, rated 9.3, exploitable without authentication, in every version before 3.15.0.
We want to make one argument about it, and it is not an argument about MLflow.
The Prediction We Made, and What Happened to It
On July 22 we published a post about Langflow landing on the KEV list for the fifth time. We titled it Go Find Yours Before the Sixth.
The sixth arrived on August 4. CVE-2026-9198, code injection, and the KEV entry's own wording is the part to read: it allows unauthenticated attackers to achieve full remote code execution on default Langflow deployments.
We are not claiming any special foresight. Predicting that a product on its fifth KEV entry will earn a sixth is not clairvoyance, it is arithmetic. We are pointing at it because the prediction was cheap, dated, published, and correct — and because the same arithmetic now applies to a much larger family of software than one drag-and-drop agent builder.
The Thing These Products Have in Common
Langflow, MLflow, and most of the tooling in this layer were designed as laboratory instruments. You run them on a workstation or a trusted subnet, you point a notebook at them, you get on with your work. In that setting an unauthenticated control plane is not negligence, it is ergonomics.
Then the model goes to production, the platform team puts the tracking server somewhere durable, a load balancer appears, and a tool built on the assumption of a trusted LAN acquires a public address. Nobody made a decision to expose an unauthenticated API to the internet. It happened as a side effect of the thing succeeding.
MLflow's specific failure is textbook. The default Tracking Server exposes the model-registry webhooks API with no authentication in front of it. An SSRF protection was added in version 3.10.0. It could be bypassed. Both of those are ordinary bugs of the kind every project ships. The reason this one is on the KEV catalog three days after the CVE was assigned is not the quality of the bug — it is that the surface was reachable and anonymous in the first place.
The Prize Is Not the Model
Here is where the MLflow story stops being an ML story.
An SSRF in a tracking server does not get an attacker your training data, and honestly they were not asking for your training data. It gets them the ability to make the server issue requests on their behalf — including to the cloud metadata endpoint that every instance in AWS, Azure and GCP can reach at a well-known internal address.
That endpoint hands out temporary credentials for whatever role the instance is running as. In confirmed incidents the credentials were exfiltrated and used to enumerate the account, deploy cryptominers, and establish persistence by creating fresh IAM users and roles. At that point the ML platform is irrelevant. It was a door into the cloud account, and it happened to be the door nobody had put a lock on.
This is the pattern we keep writing about under the name soft-surface bleed. The hard perimeter is fine. The organisation's identity provider was never touched, MFA held, the VPN did its job. The bleed went through a trusted middle layer that was never threat-modelled as a perimeter because nobody thinks of an experiment tracker as one.
Speed, and Why Patching Windows Keep Shrinking
The CVE was assigned on August 17. watchTowr reported widespread internet-wide scanning for exposed MLflow instances within hours. CISA catalogued it on August 19.
Two days from identifier to federal patch mandate. There was no period during which this was a theoretical concern that responsible teams could schedule around a sprint boundary.
We have written the mechanism behind that compression more than once, most bluntly in March when Langflow went from advisory to in-the-wild exploitation in twenty hours with no public proof-of-concept in existence — attackers built working exploits from the advisory prose. The advisory is the exploit spec now. If your patch process assumes a quiet window between disclosure and weaponisation, that assumption expired some time last year.
What We Actually Hold on This
In the interest of not overstating: we have no first-party indicators attributed to MLflow exploitation. We are not going to dress up an absence.
What we do have is CVE-2026-64849 in our KEV index, synced the day CISA published it, and one genuinely useful adjacent item — a malicious PyPI package named mlflow-ui has been in our package deny-list since July 28, sourced from OSV. That is the other half of this surface and it is worth saying out loud: when a platform gets popular enough to be attacked at the network layer, it is simultaneously popular enough to be attacked at the install layer, by somebody registering a plausible-looking companion package and waiting for a tired engineer to type it.
Go Find Yours
The remediation is MLflow 3.15.0 or later, and you should do that. But the patch is the smaller half of the work, because the next CVE in this family is already being written and it will land in a product you have not thought about yet.
The durable question is an inventory question. Which pieces of AI and ML tooling in your estate are listening on a network interface? For each one, does it require authentication in the configuration you are actually running, not the configuration in the hardening guide you read once? Does it run with an instance role that can reach the cloud metadata service, and does that role need the permissions it has? Would you find out if it started making outbound requests to an address it has never contacted before?
If you cannot answer those in an afternoon for every AI component you own, the specific version number in this post does not matter much. Something in that layer will be on the KEV catalog again before the leaves turn, and the arithmetic that made us right about the sixth Langflow entry is not finished being right.
Was this useful, or did we miss something? Rate this post below — we read every one, and the low scores are the ones that change what we build.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=in-july-we-said-go-find-yours-before-the-sixth-the-sixth-langflow-kev-landed-august-4-now-mlflow-i
Comments