CVE-2025-52967

What it actually does

The gateway_proxy_handler in MLflow versions prior to 3.1.0 fails to validate the `gateway_path` parameter, leading to a Server-Side Request Forgery (SSRF) vulnerability. An unauthenticated, remote attacker can craft a request that compels the MLflow server to make arbitrary HTTP requests to internal network resources or external systems. This allows an attacker to use the server as a proxy to scan internal networks, interact with other services, and bypass perimeter network controls.

Why it matters to the business

An attacker can exploit this vulnerability to map an organization's internal network, discover sensitive services, and interact with internal APIs without authorization. This circumvents firewall rules and exposes the internal infrastructure to external threats, potentially leading to further system compromise, data exfiltration, or disruption of internal business operations. The vulnerability effectively turns a trusted internal server into a tool for attackers.

How an attack unfolds

An unauthenticated attacker targets a publicly accessible, vulnerable MLflow instance. The attacker sends a specially crafted HTTP request to the `gateway_proxy_handler` endpoint, embedding a URL to an internal service (e.g., an internal API, a database administration panel, or a cloud metadata service) within the `gateway_path` parameter. Due to the lack of validation, the MLflow server processes this request and forwards it to the specified internal destination. By analyzing the responses or timing differences, the attacker can enumerate internal services, probe for vulnerabilities, and potentially access or modify data on systems that trust requests from the MLflow server's IP address.

How to fix it

The primary remediation is to upgrade MLflow to version 3.1.0 or a later version. For users building from source, the fix is included in git commit `39a419b4ec8fd11b59b3e50ab397042a490f2324`. If an immediate upgrade is not feasible, implement strict egress filtering on the MLflow server to prevent it from making unauthorized outbound network connections. These firewall or network security group rules should block all outbound traffic by default, only allowing connections to known, required services. Additionally, consider placing the MLflow instance behind a Web Application Firewall (WAF) configured to block requests containing URLs or IP addresses in the `gateway_path` parameter.

How to confirm the fix worked

To confirm remediation, verify that the installed MLflow version is 3.1.0 or newer. To test for the vulnerability's presence, a security engineer can send a crafted request to the `gateway_proxy_handler` endpoint. The `gateway_path` parameter should be set to a URL controlled by the tester (e.g., a Burp Collaborator or Interactsh domain). If the MLflow server is vulnerable, it will make an HTTP request to the specified callback URL. A patched or properly mitigated server will not make this outbound request. This testing should be conducted in a controlled, non-production environment.

Typical attack path

1. An attacker identifies a public-facing MLflow server running a version prior to 3.1.0.
2. The attacker crafts a malicious HTTP request to the server's `gateway_proxy_handler` endpoint.
3. The request's `gateway_path` parameter is manipulated to contain a URL pointing to a target on the internal network or a cloud metadata service.
4. The vulnerable MLflow server receives the request and, without proper validation, initiates a new connection to the attacker-specified internal target.
5. The attacker observes the server's response or connection timing to gather information about the internal network, effectively using the MLflow server as a blind proxy for reconnaissance and further attacks.

How to detect it

To detect exploitation, monitor network traffic originating from MLflow servers. Look for anomalous outbound HTTP/S requests, particularly those directed at internal IP address ranges (RFC1918), loopback addresses, or cloud provider metadata services (e.g., 169.254.169.254). Review web server access logs for the MLflow instance, filtering for requests to the `gateway_proxy_handler` endpoint. Examine these requests for parameters that contain full URLs, IP addresses, or domain names, as these are strong indicators of an exploitation attempt.

• Outbound network connections from an MLflow server process to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Outbound network connections from an MLflow server process to 169.254.169.254.
• Web server log entries showing requests to a `gateway_proxy_handler` where the request parameters contain 'http://' or 'https://'.
• Web server log entries showing requests to a `gateway_proxy_handler` where request parameters contain IP addresses.

What your security team should do

• Immediately upgrade all MLflow instances to version 3.1.0 or later.
• If patching is not immediately possible, apply strict egress filtering rules to all MLflow servers to block outbound connections to internal IP ranges and cloud metadata endpoints.
• Audit your environment to identify all MLflow instances and ensure they are included in your vulnerability management program.
• Review web server and WAF logs for historical requests to the `gateway_proxy_handler` endpoint that contain suspicious patterns like IP addresses or domain names.