MLflow Webhook SSRF: Unauthenticated Redirect Bypass Enables Full Read of Internal Services and Cloud Metadata (CVE-2026-64849)

A newly disclosed GitHub Security Advisory (GHSA-7gwp-5pfp-969j, CVE-2026-64849, CVSS 9.3) reports an unauthenticated SSRF in MLflow's model-registry webhook feature.

What Was Reported

According to the advisory, a default MLflow Tracking Server (mlflow server, no auth, SQLite backend) exposes the webhooks API without authentication, including a synchronous POST /api/2.0/mlflow/webhooks/{id}/test endpoint that reflects the upstream HTTP response — status and body — back to the caller. An existing SSRF guard, _validate_webhook_url (added in PR #20747, shipped in MLflow 3.10.0), resolves the webhook hostname via socket.getaddrinfo and rejects non-public IPs, but the delivery code (mlflow/webhooks/delivery.py) never sets allow_redirects=False and never pins the validated IP to the actual connection. The advisory describes an attacker registering a webhook pointing at an attacker-controlled public HTTPS host — which passes the guard — that then issues a 302 redirect to an internal or cloud-metadata address (e.g. 169.254.169.254 or 127.0.0.1). MLflow follows the redirect without re-validating it. A DNS-rebinding variant is also described, since the guard's resolution and the actual connection's resolution happen independently with no pinning.

The advisory includes a PoC confirmed live against mlflow==3.13.0, showing the /test endpoint returning contents fetched from an internal service via the redirect. It also notes that 307/308 redirects preserve the original POST method and body, which the advisory says could let an attacker relay attacker-controlled POST payloads to internal management endpoints that act on POST (the advisory names Docker daemon, Elasticsearch, and Spring Boot Actuator as illustrative examples of that class of target, not as confirmed-exploited services). The report attributes original private discovery to a researcher on 2026-06-12, with independent public discovery and disclosure by a second researcher on 2026-06-26.

Why It Matters

This affects any MLflow Tracking Server run with default settings — no authentication required, and the webhook auth plugin is opt-in rather than default. Per the advisory, the impact is a full-read SSRF: successful exploitation can expose cloud instance metadata (e.g., AWS IMDS IAM credentials), reach internal-only admin services behind the network boundary, and enable internal port/host scanning — all from an unauthenticated request against a default deployment. Organizations running MLflow tracking servers reachable from untrusted networks, or exposed more broadly than intended, are at elevated risk. The advisory characterizes this as an incomplete fix of the earlier SSRF guard rather than a net-new class of bug.

What Defenders Should Do Now

• Inventory MLflow Tracking Server instances and confirm which version is deployed; the advisory states this is confirmed present through 3.13.0 and on master as of the report.
• Restrict network reachability to MLflow tracking servers — treat them as internal-only services and place them behind authentication/network controls rather than relying on built-in SSRF protections.
• Review or disable the webhooks feature where not in active use, and audit any existing registered webhook URLs for unexpected destinations.
• Hunt for outbound requests from the MLflow server host to loopback, link-local (169.254.0.0/16), or RFC1918 addresses, and for calls to /api/2.0/mlflow/webhooks/*/test from unexpected or unauthenticated sources in server/proxy logs.
• If cloud-hosted, ensure IMDSv2 (or equivalent metadata-service hardening) is enforced so a successful SSRF cannot retrieve instance credentials even if the application-layer guard is bypassed.
• Track the upstream fix referenced in the advisory (PR #24258, connection-time SSRF protection via a protected HTTP adapter that validates the peer IP after socket connect) and apply it once available in a release.

Developing Intel

This is fresh, net-new intelligence based on a single GitHub Security Advisory; details may be refined as the vendor finalizes a patched release and as the community validates the PoC further. Consult the original advisory for the authoritative technical details and PoC: GHSA-7gwp-5pfp-969j.