MLflow: unauthenticated webhook test follows redirects, turning the tracking server into an SSRF proxy

Impact

The webhook test endpoint needs no authentication and validates only the URL it is handed; delivery then follows redirects and re-resolves the hostname without pinning the address that passed validation. An attacker who can reach the tracking server's HTTP port makes it issue requests to anything it can route to and gets both the response status and the response body back. On a GPU fleet that means the cloud metadata service of the node or pod running MLflow, so the instance role or workload identity that MLflow uses to write to the model and artifact buckets can be read out, along with any internal service that trusts requests originating inside the cluster. MLflow is usually deployed as one shared tracking server for the whole fleet, so a single reachable instance exposes the credentials that every training and serving job depends on.

Who can reach it

Anyone who can send HTTP to the MLflow tracking server, with no credentials and no MLflow account. Exposure is decided entirely by who can route to the tracking port - an internet-facing or cluster-wide-reachable MLflow is fully exploitable.

What to do

Upgrade to MLflow 3.15.0 and restart the tracking server; this is a Python service restart, not a node action, and running jobs only lose their tracking connection briefly. Until the upgrade lands, put the tracking server behind authentication or a network policy that keeps it off the metadata address and off internal admin services, and rotate any cloud credential the MLflow pod or instance could have reached.

References