A critical server-side request forgery (SSRF) vulnerability in MLflow, an open-source platform for managing machine learning workflows, is currently being actively exploited by threat actors. This flaw, identified as CVE-2026-64849 with a CVSS 3.1 score of 9.3, affects all MLflow versions prior to 3.15.0. The vulnerability allows unauthenticated attackers to send crafted requests to MLflow’s Tracking Server, potentially leading to unauthorized access to internal resources and sensitive data.
Details of the Vulnerability
MLflow’s Tracking Server, when initiated with the default `mlflow server` command, operates without mandatory authentication and utilizes a local SQLite backend. This configuration exposes the model-registry webhooks API to untrusted network traffic. The primary attack vector involves sending an unauthenticated POST request to the `/api/2.0/mlflow/webhooks/{id}/test` endpoint. Instead of merely triggering the designated webhook, this endpoint reflects the full upstream HTTP status code and response body back to the requester, effectively converting a standard blind request-forgery into a high-impact, full-read primitive.
Although MLflow introduced the `_validate_webhook_url()` function in version 3.10.0 to reject private and cloud metadata addresses, this validation only assesses the initial destination. The delivery handler in `mlflow/webhooks/delivery.py` continues to follow HTTP redirects without re-validating the secondary address. Consequently, an attacker can configure a public endpoint that passes initial checks and returns an HTTP 302 redirect pointing toward link-local cloud metadata services or internal loopback interfaces. Additionally, since the hostname resolves again after the initial allowlist verification, the interface remains susceptible to DNS-rebinding attacks.
Active Exploitation and Impact
Monitoring by watchTowr Intel, through its global Attacker Eye honeypot sensor network, has detected adversaries targeting internet-exposed MLflow instances within hours of the public disclosure of this vulnerability. These attackers aim to harvest cloud credentials and sensitive deployment tokens. On major cloud platforms such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform, the reflected response enables attackers to extract temporary IAM role credentials, OAuth tokens, and environment configurations from the link-local metadata address at `http://169.254.169.254/`. Beyond cloud provider metadata, the exploit can query internal microservices and loopback administrative consoles that implicitly trust the host environment.
Mitigation Measures
The maintainers have addressed the redirect and DNS-rebinding exposure in MLflow version 3.15.0. Organizations operating internet-facing or shared Tracking Servers are strongly advised to upgrade to version 3.15.0 or later immediately. Since applying patches does not revoke credentials that may have already been exfiltrated, security teams should audit access logs for requests directed to `/webhooks/*/test`, rotate all cloud IAM keys and API secrets assigned to host instances, and enforce network egress filtering to restrict unauthorized communication with link-local metadata addresses. Implementing rigorous emergency patch management and placing MLflow behind identity-aware proxies can help ensure that internal tracking portals remain isolated from public scanning networks.
This incident underscores the critical importance of securing machine learning infrastructure against emerging threats. As MLflow and similar platforms become integral to data science workflows, they present attractive targets for attackers seeking to exploit vulnerabilities for unauthorized access and data exfiltration. Organizations must prioritize timely patching, robust access controls, and continuous monitoring to safeguard their machine learning environments.
