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

Related entries

• sentence-transformers: local model directory executes Python despite trust_remote_code=FalseCVE-2026-68770 · sentence-transformers (import_module_class trust_remote_code gate)Critical
• LMDeploy: unauthenticated p2p endpoints let a remote peer deliver a pickle payload for engine RCECVE-2026-76850 · LMDeploy (disaggregated serving ZMQ peer channel)Critical
• Headroom: client-supplied x-headroom-user-id header is trusted as identity, exposing other users' memoryCVE-2026-77776 · Headroom LLM proxy (x-headroom-user-id header treated as identity)Critical
• llama.cpp: use-after-free in the RPC server GRAPH_RECOMPUTE handler gives unauthenticated RCECVE-2026-39909 · llama.cpp RPC server (GRAPH_RECOMPUTE handler)Critical
• llama.cpp llama-server: use-after-free on the vocab pointer during idle sleep gives unauthenticated RCECVE-2026-43631 · llama.cpp llama-server (--sleep-idle-seconds idle transition)Critical
• Ray (`/log_proxy`): SSRF from the dashboardCVE-2023-48023 · Ray (`/log_proxy`)Critical