MLflow Webhook Test SSRF via Redirect Bypass (CVE-2026-64849)

Technical Analysis

The POST /api/2.0/mlflow/webhooks/{id}/test endpoint validates the initial webhook URL via _validate_webhook_url() to block internal/private addresses, but the actual HTTP request in mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without re-validating or pinning to the originally approved IP. An attacker registers or triggers a test against a webhook URL that returns an HTTP redirect to an internal address (e.g., 169.254.169.254 for cloud metadata, or internal admin panels), and the endpoint's response_status and response_body are echoed back, leaking cloud IAM credentials, internal service data, or network topology. Because the endpoint requires no authentication, this is a fully remote, unauthenticated SSRF that crosses the trust boundary between MLflow's control plane and the underlying host/cloud network, potentially enabling full cloud account takeover on platforms where MLflow runs with an attached instance role.

Affected Systems

MLflow

Detection Signatures

• Webhook test requests followed by 3xx redirect responses to RFC1918/link-local addresses (e.g., 169.254.169.254, 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16)
• Unauthenticated calls to POST /api/2.0/mlflow/webhooks/{id}/test in access logs
• Webhook URLs registered pointing to attacker-controlled domains that issue Location headers to internal IPs
• Unexpected access to cloud metadata service (IMDS) endpoints originating from MLflow server process
• Spikes in response_body content containing AWS/GCP/Azure credential-like strings in MLflow webhook test logs

Remediation Steps

1. 1

   Upgrade MLflow

   Update to MLflow 3.15.0 or later, which fixes the redirect validation bypass.

2. 2

   Re-validate on redirect

   If patching is delayed, deploy a network-level proxy or WAF rule that blocks outbound requests from the MLflow host to private/link-local IP ranges regardless of redirect chains.

3. 3

   Restrict IMDS access

   Enforce IMDSv2 or metadata service network policies (e.g., hop-limit restrictions, firewall rules) so that even successful SSRF cannot reach cloud metadata endpoints.

4. 4

   Require authentication on webhook endpoints

   Add authentication/authorization controls in front of the webhook test API as defense-in-depth, since it currently allows unauthenticated triggering.

5. 5

   Audit webhook configurations

   Review all existing MLflow webhook URLs for suspicious redirect chains or recently modified targets, and rotate any credentials potentially exposed via metadata service access.