CVE-2026-64849

What is MLflow?

MLflow is a widely deployed open-source platform for managing the machine learning lifecycle — experiment tracking, model packaging, and the model registry. Its central component is the Tracking Server, an HTTP service that data scientists point their training code at to log runs, parameters, and artifacts.

Two deployment realities make MLflow a high-value target. First, it ships without authentication enabled by default, and because it is treated as internal developer tooling it is frequently left unauthenticated behind nothing more than network placement. Second, it usually runs inside a cloud VPC with an attached instance role so it can write artifacts to object storage — which means the host holds cloud credentials reachable through the instance metadata service.

An SSRF primitive on such a host is therefore not a minor information leak. It is a direct path from an unauthenticated HTTP request to cloud account credentials.

Overview

CVE-2026-64849 is an unauthenticated server-side request forgery (CWE-918) in MLflow's model-registry webhook testing functionality. An attacker who can reach the Tracking Server can make it issue HTTP requests to arbitrary internal addresses — including cloud metadata endpoints — and read the response back. CVSS 3.1 base score is 9.3 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N).

The CVE was assigned on 2026-08-17, and indiscriminate scanning for exposed instances began within hours. CISA added it to KEV on 2026-08-19 — a two-day turnaround from CVE assignment, among the fastest KEV additions on record — with a deadline of 2026-09-02.

Affected Versions

Version 3.15.0 pins the validated address at connection time, closing the redirect gap described below.

Technical Details

A default MLflow Tracking Server exposes the endpoint:

POST /api/2.0/mlflow/webhooks/{id}/test

without authentication. The endpoint exists so users can verify a registered webhook works.

The flaw is a validate-then-follow gap. MLflow validates the webhook's originally supplied URL, but once an HTTP redirect is returned it does not re-validate or pin the resolved address before following it. An attacker registers or targets a webhook pointing at a host they control, which responds with a redirect to an internal address — and MLflow follows it. This is why the bug bypasses MLflow's prior SSRF fixes: those hardened the submitted URL, not the post-redirect destination.

Two properties raise the severity above a typical SSRF:

• It is not blind. The endpoint returns response_status and response_body to the caller, so the attacker reads whatever the internal service replied with — including credential material from a metadata endpoint.
• S:C (Scope: Changed). The CVSS vector formally recognises that impact crosses a trust boundary: a request to the MLflow service yields secrets belonging to the surrounding cloud account.

The practical exploitation chain is short: unauthenticated request → redirect to 169.254.169.254 or another internal service → instance-role credentials returned in the response body → authenticated access to the victim's cloud environment.

Discovery

Discovered and reported by watchTowr. watchTowr also detected the subsequent exploitation using its global honeypot telemetry, which is how the near-immediate scanning activity was established.

Exploitation Context

Exploitation began within hours of the CVE being assigned on 2026-08-17, and the activity is described as indiscriminate internet-wide scanning for exposed MLflow instances rather than targeted operations.

Attackers are using the SSRF to reach cloud metadata services directly and exfiltrate cloud credentials and secrets from well-known internal IP addresses and service endpoints. Cloud-hosted MLflow deployments are the specific focus, which follows from the attack's economics: an on-premises MLflow with no instance role yields far less than one running on a cloud VM with a permissive role attached.

The speed here is the story. The gap between CVE assignment and mass scanning was measured in hours, and CISA's KEV addition followed in two days — leaving effectively no window in which an exposed, unpatched instance could be considered safe.

Remediation

1. Upgrade to MLflow 3.15.0 or later. This is the complete fix; it pins the validated address at connection time so redirects cannot retarget the request.
2. Never expose the Tracking Server to the internet. Place it behind a VPN or private network boundary.
3. Put authentication in front of it — an authenticating reverse proxy at minimum. The vulnerable endpoint requires no credentials, so network and proxy controls are what stand between an attacker and the primitive.
4. Enforce IMDSv2 (or your cloud's equivalent session-oriented metadata protection) and block egress to 169.254.169.254 from the MLflow host or pod. This breaks the credential-theft step even if an SSRF exists.
5. Rotate credentials reachable from the host — the instance role, any stored artifact-store keys, database connection strings, and secrets in environment variables — if the instance was exposed on or after 2026-08-17.
6. Review access logs for POST requests to /api/2.0/mlflow/webhooks/*/test and for outbound requests from the MLflow host to link-local or internal addresses.
7. Audit registered webhooks for entries pointing at unfamiliar external hosts.