MLflow — unauthenticated full-read SSRF in webhook delivery; the URL guard validates the resolved address but never pins it, and delivery follows redirects unvalidated. CISA KEV 2026-08-19; fixed in 3.15.0.

CVE-2026-64849 — MLflow: the SSRF guard resolves the webhook host and then throws the answer away, so one redirect turns an unauthenticated tracking server into a reader of its own cloud credentials

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on 2026-08-19, with a remediation date of 2026-09-02, describing a server-side request forgery in MLflow "that can allow attackers to reach internal or cloud metadata services and receive response_status and response_body" (CISA Known Exploited Vulnerabilities catalog, version 2026.08.19). The remediation date is a US federal compliance clock and carries no weight here; the listing itself is what matters, because it is a government determination that this is being used against real deployments rather than a theoretical severity rating.

The mechanism is a guard that does its work and then discards the result. On a default MLflow tracking server — started with mlflow server, no authentication, the default SQLite backend — the model-registry webhooks API is reachable without credentials, and it includes a synchronous test endpoint that returns the upstream response status and body to whoever called it; the only webhook authorisation MLflow ships lives in an optional auth plugin that is not loaded by default (GitHub Security Advisory GHSA-7gwp-5pfp-969j, 2026-08-17). When a webhook is registered, the URL validator resolves the hostname and rejects any address that is not globally routable, which blocks the naive attempt to point a webhook at loopback or a metadata address. But, as the advisory puts it, "The resolved IP is never carried into the connection" (GHSA-7gwp-5pfp-969j, 2026-08-17) — delivery re-resolves the hostname independently and follows HTTP redirects without re-validating the redirect target. An attacker registers a webhook pointing at a public HTTPS host they control, which passes validation, and then fires the unauthenticated test endpoint; the host answers with a redirect to an internal or instance-metadata address, MLflow follows it, and the response body comes back in the test result. The same missing re-validation yields a second primitive: redirect status codes that preserve the method and body turn the same path into a blind write against internal management endpoints that act on POST. Neither requires authentication on a default open-source server, and the researcher confirmed the read primitive live against MLflow 3.13.0.

Detection sits in egress rather than on the application. The observable is the tracking-server host making outbound connections to link-local or private-range destinations — above all the cloud instance-metadata address — with the request originating from the MLflow process itself, and in web-access telemetry the preceding pair of unauthenticated requests that create a webhook and then call its test endpoint. Triage: a legitimate webhook target is operator-configured, stable, and resolves to the same external service every time; the discriminators are a webhook registered and tested within seconds of each other by an unauthenticated caller, and a delivery attempt whose final destination is inside the network the server sits in rather than the host that was registered. Neither is a normal shape for a notification integration.