Security researchers have identified a critical vulnerability in MLflow that exposes default tracking server installations to unauthenticated Server-Side Request Forgery (SSRF) and attackers are already exploiting it.

This flaw allows remote, unauthenticated attackers to read sensitive data from internal network services or cloud metadata endpoints and potentially interact with internal management services through POST requests. The bug (CVE-2026-64849) is being exploited in the wild, and researchers are urging organizations to patch their instances of MLflow as quickly as possible. 

“Within hours of CVE assignment, watchTowr Intel via Attacker Eye, our global honeypot network, observed attackers targeting cloud-hosted MLflow systems in an attempt to extract credentials and secrets,” watchTowr Labs said.

“All versions before 3.15.0 affected. Prioritize patching, monitor for compromise, review if sensitive credentials were exposed.”

MLflow is an open source platform specifically designed for AI agents, LLMs, and ML models. 

“Within hours of CVE assignment, watchTowr Intel via Attacker Eye, our global honeypot network, observed attackers targeting cloud-hosted MLflow systems in an attempt to extract credentials and secrets."

The vulnerability affects MLflow versions prior to 3.15.0. The core issue lies in how the server processes webhook deliveries, specifically regarding the _validate_webhook_url function introduced in version 3.10.0. While this guard was intended to prevent SSRF by resolving hostnames and rejecting non-public IP addresses, it fails to "pin" the validated IP address to the connection.

Attackers can bypass this protection by providing a URL that passes the initial validation check but returns an HTTP 302 redirect. Because the MLflow delivery mechanism follows these redirects without re-validating the target address, an attacker can redirect the server to internal resources like 127.0.0.1 or cloud metadata services such as 169.254.169.254. Since the POST /api/2.0/mlflow/webhooks/{id}/testendpoint reflects the response body from the upstream request, the server essentially acts as a proxy, leaking internal information back to the attacker.

Exploitation of the vulnerability is relatively straightforward. 

“An attacker hosts a public HTTPS endpoint that passes the guard and returns 302 Location: http://169.254.169.254/... (or http://127.0.0.1:...); MLflow follows it and never re-validates the redirect target. Because /test reflects the response body, this is an unauthenticated full-read SSRF on a default server,” the advisory says. 

The impact extends beyond mere information disclosure. By utilizing HTTP 307 or 308 redirects, which maintain the original request method and body, attackers can also perform blind writes. This could potentially allow unauthorized interactions with internal management endpoints that rely on POST requests, such as the Docker daemon or Spring Boot Actuator, depending on the network environment.

This vulnerability is particularly dangerous because the model-registry webhooks API is enabled and unauthenticated by default in many MLflow tracking server configurations. The maintainers of MLflow have addressed this issue in version 3.15.0. Organizations utilizing MLflow are advised to upgrade to this version immediately to mitigate the risk of unauthorized data access and potential command execution within their internal infrastructure.