MLflow versions prior to 3.15.0 carry a critical unauthenticated server-side request forgery (SSRF) vulnerability in the model-registry webhooks API, tracked as CVE-2026-64849 and GHSA-7gwp-5pfp-969j1. The fix ships in MLflow 3.15.0.
The flaw affects the default MLflow Tracking Server configuration — no authentication enabled, default SQLite backend — where the webhooks API is exposed without any access control. The only webhook authorization lives in an optional auth plugin that is not loaded by default.
Mechanism. The synchronous `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint returns the upstream response status and body directly to the caller. An SSRF guard introduced in PR #20747 and shipped in MLflow 3.10.0, `_validate_webhook_url`, resolves the webhook hostname and rejects non-public IPs. However, the guard is bypassable: MLflow follows HTTP redirects without setting `allow_redirects=False` and never pins the validated IP. An attacker hosts a public HTTPS endpoint that passes the initial validation, then returns a `302 Location` redirect to an internal address such as `http://169.254.169.254/...` or `http://127.0.0.1:...`. MLflow follows the redirect and never re-validates the target. Because the `/test` endpoint reflects the response body, the result is an unauthenticated full-read SSRF on a default server.
The vulnerability was confirmed live against mlflow==3.13.0 on the default SQLite server.
Fix. PR #24258 introduces SSRFProtectedHTTPAdapter, which validates the peer IP of each connected socket immediately after `connect()`, before any TLS or HTTP exchange. Because each redirect opens a new connection through the protected pool, redirect targets are also covered by the validation.
Operational context. This is the third MLflow security advisory covered in recent weeks. CVE-2026-69148, a high-severity auth bypass in the CreateModelVersion API, was disclosed on August 17, 2026 ctx. On the same date, CVE-2026-69146, a medium-severity auth bypass in the LogInputs endpoint, was also patched ctx.
ANALYSIS The pattern across these three advisories — CVE-2026-64849, CVE-2026-69148, and CVE-2026-69146 — centers on MLflow's default-open posture: endpoints that carry no authentication unless an optional plugin is explicitly loaded, combined with incomplete input validation. The critical severity of the SSRF is amplified by the fact that cloud-hosted MLflow instances running default configurations would expose internal metadata services (such as AWS IMDS at 169.254.169.254) to unauthenticated external callers.
The fix's approach — connection-time IP validation via a custom HTTP adapter rather than pre-request hostname resolution — addresses both the redirect-based bypass and DNS rebinding, since the check occurs on the actual socket peer rather than on a cached DNS result.
Teams running MLflow Tracking Servers should upgrade to 3.15.0 immediately, particularly any instances reachable from untrusted networks.