MLflow 2.x: Actively Exploited, Fixed Only in 3.15 — and Never Declared End of Life
MLflow carries an actively exploited, unauthenticated SSRF — CVE-2026-64849, CVSS 9.3 critical. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-19; scanning began within hours of CVE assignment. Attackers use it to reach internal and cloud metadata services — the classic path to stolen cloud credentials. The fix exists only in MLflow 3.15.0 and later. If you run any 2.x release, there is no patch for you and there never will be.
Key Dates at a Glance
- CVE-2026-64849 added to CISA KEV: 2026-08-19; federal remediation deadline: 2026-09-02
- First patched version: MLflow 3.15.0 (released 2026-07-31, per GHSA-7gwp-5pfp-969j)
- MLflow 2.x: final release 2.22.5 shipped 2026-05-12 — no release since, no backport, no EOL announcement
- MLflow 3.x first shipped 2025-06-10
- Ray CVE-2025-62593 added to KEV 2026-08-17 (patched in Ray 2.52.0, released 2025-11-21)
- Langflow: six KEV entries since 2025-05-05, the latest added 2026-08-04
What the vulnerability actually is
CVE-2026-64849 is a server-side request forgery in MLflow’s webhook delivery. The URL validation in _validate_webhook_url can be bypassed with unvalidated HTTP redirects or DNS rebinding, letting an unauthenticated attacker make the MLflow tracking server fetch arbitrary internal URLs and read the responses. Pointed at a cloud provider’s metadata endpoint, that reads out the instance’s temporary credentials — which is why CISA’s catalog entry describes attackers reaching internal or cloud metadata services. GitHub’s advisory (GHSA-7gwp-5pfp-969j) rates it CVSS 9.3, critical.
One discrepancy worth naming: MLflow’s own advisory does not state a patched version. The GitHub Security Advisory database — the authoritative record for package ecosystems — lists the vulnerable range as everything below 3.15.0 and the first patched version as 3.15.0. That range includes every 2.x and 1.x release ever shipped.
MLflow 2.x is end of life — nobody announced it
MLflow publishes no lifecycle policy: no support windows, no EOL dates, no security-maintenance commitments. Until this week that was an academic complaint. Now it is operational: the 2.x line — the default MLflow for three years, still pinned in thousands of requirements.txt files — has been silent since 2026-05-12, received no backport of an actively exploited critical fix, and got no announcement that support had ended. That is end of life in every way that matters, declared by silence.
| Line | First release | Status | Your move |
|---|---|---|---|
| MLflow 3.x | 2025-06-10 | Active — all fixes land here | Be on 3.15.0 or later. Anything earlier in 3.x is vulnerable to CVE-2026-64849. |
| MLflow 2.x | 2022-11-15 | De facto EOL — no release since 2.22.5 | Migrate to 3.15.0+. No patch exists for 2.x and none is coming. |
| MLflow 1.x | 2019-06-04 | EOL — last release 2023-04-05 | Same, with a longer path. |
The pattern: third AI infrastructure tool on KEV in six weeks
MLflow is not an outlier. It is the third AI infrastructure tool to land in CISA’s actively-exploited catalog since early July — and none of the three publishes an end-of-life policy:
| Tool | CVE | KEV added | Fixed in |
|---|---|---|---|
| MLflow (ML experiment tracking) | CVE-2026-64849 — SSRF, CVSS 9.3 | 2026-08-19 (due 2026-09-02) | 3.15.0 only — no 2.x backport |
| Ray (distributed compute) | CVE-2025-62593 — code injection / RCE | 2026-08-17 (due 2026-08-20) | 2.52.0, released 2025-11-21 — the fix existed nine months before exploitation forced it onto KEV |
| Langflow (LLM app builder) | Six KEV entries since 2025-05-05 | Most recent 2026-08-04 | Per-CVE — run the newest release, always |
The common thread: ML tooling runs with cloud credentials, sits on networks its operators think of as internal, and follows a release culture where old versions simply stop existing rather than being formally retired. Platform teams inherit a patching burden the projects themselves never promised to carry.
What to do this week
1. Find your MLflow versions. pip show mlflow per environment, or search your dependency manifests for mlflow pins. Anything below 3.15.0 is vulnerable to an actively exploited critical CVE.
2. Get tracking servers off the open internet. The flaw is unauthenticated. An MLflow tracking server reachable from outside your network is currently being scanned for.
3. Upgrade to 3.15.0 or later. For 3.x deployments that is routine. For 2.x deployments it is a major-version migration — and unlike PHP or Java, no extended-support vendor we track offers post-EOL patching for MLflow. There is no paid bridge. Migration is the only exit.
4. Rotate any credentials an exposed server could have leaked. If a tracking server below 3.15.0 was internet-reachable, treat its instance credentials as compromised — the exploit reads cloud metadata.
Track MLflow — and everything else in your stack
MLflow, Ray and the rest of your stack’s end-of-life status, risk scores and KEV exposure — checked daily.
MLflow lifecycle & risk →