MLflow CVE-2026-64849: Exploited Unauthenticated SSRF

What to do

1. Check the version on every tracking server (pip show mlflow) and upgrade to 3.16.0 or later; 3.17.2 is current.
2. Until upgraded, take the server off public networks or put it behind a VPN or identity-aware proxy.
3. Block the MLflow host from reaching 169.254.169.254 and other link-local metadata addresses, and enforce IMDSv2 on AWS.
4. List webhooks (GET /api/2.0/mlflow/webhooks) and delete any you did not create.
5. If the server was reachable while vulnerable, rotate the host's cloud credentials and any secrets reachable from it, and scope its IAM role to least privilege.

How to check if you are affected or compromised

• Search access logs for POST /api/2.0/mlflow/webhooks and POST /api/2.0/mlflow/webhooks/<id>/test from unknown clients.
• Review registered webhooks for destination URLs on domains you do not recognize.
• Check CloudTrail, GCP Cloud Audit Logs or Azure Activity Logs for the MLflow host's role or identity being used from unfamiliar IP addresses.
• Look for unexpected requests from the MLflow host to internal services or metadata endpoints in VPC flow or proxy logs.

What happened#

MLflow, the open-source platform many teams use to track experiments and register models, published GHSA-7gwp-5pfp-969j on August 2, 2026. The flaw is a server-side request forgery in the model-registry webhooks feature. The CVE (CVE-2026-64849, CVSS 3.1 9.3) was assigned on August 17.

On a default tracking server, the webhooks API needs no authentication. That includes a "test" endpoint that makes the server call the webhook URL and returns the response status and body to whoever asked. MLflow 3.10.0 added a check that webhook URLs resolve to public addresses, but the check could be sidestepped: the server followed redirects without re-checking where they led, and it looked up the hostname again when connecting. An unauthenticated attacker could therefore make the server fetch internal addresses, including cloud instance-metadata services that hand out credentials, and read the replies.

The bug was reported privately on June 12. It was also reported publicly by an independent finder on June 26, so the weakness was visible before the fix shipped. PR #24258 fixed it by checking the address of every actual connection, redirects included. It shipped in MLflow 3.15.0 on July 31. The advisory adds that four IPv6-transition bypasses of that fix were closed in 3.16.0.

Who is affected#

The CVE record lists MLflow 3.3.0 (the release that introduced webhooks) through 3.14.x. The GitHub advisory lists 3.10.0 through 3.14.x, the releases with the bypassable check. Treat the whole 3.3 to 3.14 range as exposed. Webhooks need a database-backed store, and the default SQLite backend qualifies.

Exposure depends on where the server listens. mlflow server binds to 127.0.0.1 by default, but shared tracking servers are commonly started with --host 0.0.0.0 in containers, on Kubernetes or on cloud VMs. Those VMs usually carry an IAM role or service account, which is exactly what a metadata request returns. The optional basic-auth plugin helps, but the Cloud Security Alliance notes that any authenticated low-privilege user could still register a webhook.

Do you really need to act?#

Yes, if anyone outside a small trusted group can reach the server. watchTowr reported that its honeypots saw indiscriminate scanning for exposed MLflow instances within hours of the CVE being assigned. It says attackers are using the flaw to reach cloud metadata services and steal credentials and secrets. CISA added the CVE to KEV on August 19, with a September 2 deadline. Stolen instance credentials can lead into model artifacts in object storage, training data and the wider cloud account, so the blast radius is set by the host's IAM role, not by MLflow.

A laptop running mlflow ui on localhost is not realistically exposed to this. A tracking server on an internal network is lower risk but still reachable by anyone already inside.

What to do now#

1. Run pip show mlflow on each server and upgrade with pip install -U "mlflow>=3.16.0", or rebuild the image. 3.17.2 is current.
2. Until upgraded, remove public exposure. Put the server behind a VPN or an identity-aware proxy, and keep --host on 127.0.0.1 where possible.
3. Block egress from the MLflow host or pod to 169.254.169.254 and other link-local ranges, and enforce IMDSv2 on AWS, as the Cloud Security Alliance recommends.
4. List webhooks with curl -s http://<host>:5000/api/2.0/mlflow/webhooks and delete any you did not create.
5. If the server was reachable while vulnerable, rotate the host's cloud credentials and any secrets it can reach, and narrow its IAM role.

How to tell if you were hit#

In proxy or server access logs, look for POST /api/2.0/mlflow/webhooks followed by POST /api/2.0/mlflow/webhooks/<id>/test from clients you do not know. The Cloud Security Alliance advises treating any webhook not created by a known process as a possible sign of prior exploitation. Then check your cloud audit trail (CloudTrail, GCP Cloud Audit Logs or Azure Activity Log) for the MLflow host's role or managed identity being used from unfamiliar IP addresses, or for unusual enumeration shortly after the server became reachable.

Timeline#

• Jun 12, 2026 — Reported privately to MLflow.
• Jun 26, 2026 — Independent public report in issue #24179.
• Jul 2, 2026 — Fix merged in PR #24258.
• Jul 31, 2026 — MLflow 3.15.0 released with the fix.
• Aug 2, 2026 — GitHub advisory published.
• Aug 17, 2026 — CVE published. watchTowr reports scanning within hours.
• Aug 19, 2026 — CISA adds CVE-2026-64849 to KEV.
• Sep 2, 2026 — CISA remediation deadline for federal agencies.
• Sep 4, 2026 — MLflow 3.16.0 released with IPv6-transition bypass fixes.

Vulnerability records

• CVE-2026-64849 · KEV 2026-08-19 · MLflow is an open source AI engineering platform for agents, large language models, and machine learning models.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. MLflow — GHSA-7gwp-5pfp-969j: Unauthenticated full-read SSRF in MLflow webhook delivery github.com
2. CVE record — CVE-2026-64849 cve.org
3. NVD — CVE-2026-64849 nvd.nist.gov
4. CISA — Known Exploited Vulnerabilities: CVE-2026-64849 cisa.gov
5. CISA — CISA Adds One Known Exploited Vulnerability to Catalog (Aug 19, 2026) cisa.gov
6. MLflow — PR #24258: Fix DNS-rebinding SSRF bypass in webhook delivery github.com
7. MLflow — Issue #24179: DNS rebinding bypass of webhook SSRF protection github.com
8. MLflow — Release v3.15.0 github.com
9. Cloud Security Alliance — MLflow SSRF Actively Exploited for Cloud Credential Theft labs.cloudsecurityalliance.org

Coverage and analysis

1. watchTowr — In-the-wild exploitation of MLflow CVE-2026-64849 (LinkedIn) linkedin.com
2. The Hacker News — Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secrets thehackernews.com