CVE-2026-64849

This flaw is like a “phone number check” that only verifies the first number, but then the system follows a chain of forwarding instructions (redirects) without re-checking where it ends up. If someone can reach this webhook test feature, they may be able to make MLflow contact private services (like internal network addresses or cloud metadata endpoints) and then send back what it learned—such as credentials or secrets.

This matters if you run MLflow (especially an MLflow Tracking Server) and expose it in a way that lets outsiders reach the unauthenticated webhook test endpoint. The issue is reachable in default configuration, requires no login, and needs no user action—so internet exposure meaningfully increases risk. Act with urgency if the endpoint is reachable from untrusted networks (for example, the public internet) because attackers are already exploiting it.

RED — attackers are already exploiting this vulnerability to steal cloud credentials and secrets via SSRF against MLflow Tracking Servers. Because it is unauthenticated and reachable in default configuration, a publicly reachable MLflow instance is at immediate risk. Upgrade to 3.15.0 or later without delay.

1. Confirm exposure

   • Determine your MLflow version on the server(s) that run the Tracking Server/API.
   • Verify whether the webhook test endpoint is reachable from untrusted networks (internet-facing, via VPN reachable by non-admins, or via load balancer rules).
   • Check whether any security layer already blocks outbound requests to internal networks / cloud metadata addresses (if you have network controls, confirm they are effective).

2. Validate whether you’re within the vulnerable range

   • The vulnerability affects MLflow prior to 3.15.0.
   • If your version is earlier than 3.15.0, you should assume it’s vulnerable.

3. Upgrade to the fixed version

   • Upgrade MLflow to 3.15.0 or later.
   • After upgrading, re-check that the MLflow service is running the intended version and that deployment artifacts (containers/VM images) are updated.

4. If patching is delayed (temporary containment)

   • Immediately restrict access to the MLflow web/API so the webhook test path is not reachable from the public internet or other untrusted networks.
   • If possible, tighten firewall/network rules to prevent the MLflow server from reaching internal/private IP ranges and cloud metadata services (this limits SSRF impact even if an attacker tries to redirect).

5. Post-upgrade monitoring

   • Review logs around the webhook test activity (requests to the webhook delivery test endpoint) for indicators such as:
     • unexpected redirect chains
     • target destinations that resolve to private IP ranges or metadata service hostnames
     • repeated automated attempts
   • If you detect suspicious activity, rotate any cloud/API credentials that may have been exposed and review access logs for follow-on compromise.

Severity is high (SSRF with sensitive data exposure) and the traffic-light verdict is RED. The weakness is CWE-918 (Server-Side Request Forgery): MLflow verifies a provided webhook URL up front, but during delivery it follows HTTP redirects and re-resolves the destination without ensuring the redirected target is still the validated/allowed destination. This allows unauthenticated attackers to reach internal network resources and cloud metadata services and then obtain response data (reported as leaking cloud credentials and secrets). Exploitation has been reported in the wild (news/incident reports) against MLflow Tracking Servers. The fix is in MLflow 3.15.0. KEV listing was not found in the provided findings.