CVE-2026-64849: Lfprojects MLflow SSRF Vulnerability

CVE-2026-64849 Overview

CVE-2026-64849 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in MLflow, the open source AI engineering platform for agents, large language models, and machine learning models. The flaw affects all releases prior to 3.15.0. The unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint validates the initial webhook URL but follows HTTP redirects without pinning the validated address. Attackers can abuse this to reach internal services or cloud metadata endpoints and read the response body. CISA has added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog.

Critical Impact
Unauthenticated attackers can pivot into internal networks and exfiltrate cloud instance metadata credentials from MLflow deployments.

Affected Products

MLflow versions prior to 3.15.0
Deployments exposing the MLflow REST API to untrusted networks
MLflow instances running in AWS, Azure, or GCP with reachable instance metadata services

Discovery Timeline

2026-08-17 - CVE-2026-64849 published to the National Vulnerability Database
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-64849

Vulnerability Analysis

MLflow exposes a webhook subsystem that allows registered URLs to be invoked when model registry events occur. The POST /api/2.0/mlflow/webhooks/{id}/test endpoint permits testing webhook delivery without authentication.

The endpoint calls _validate_webhook_url() in mlflow/utils/validation.py to reject URLs pointing to loopback, link-local, or private address ranges. This check runs once on the initial URL. Delivery is then handled by mlflow/webhooks/delivery.py, which uses requests with redirect-following enabled.

When the target server returns an HTTP 3xx response, the delivery code re-resolves the redirect target hostname without re-invoking the SSRF guard. An attacker controls a public hostname that resolves to a benign address on first lookup and then redirects (or resolves via DNS rebinding) to 169.254.169.254, 127.0.0.1, or an internal RFC1918 address. The full HTTP response_status and response_body are returned to the caller, enabling data exfiltration from internal services.

Root Cause

The root cause is a Time-of-Check Time-of-Use (TOCTOU) gap between URL validation and URL resolution. The validator inspects the original hostname while the HTTP client independently resolves the redirect target. The validated IP address is not pinned to the outbound socket connection.

Attack Vector

Exploitation requires only network reachability to the MLflow server. An attacker registers a webhook pointing to an attacker-controlled domain that passes SSRF validation, then triggers the test endpoint. The attacker's server issues a redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/ or a similar internal target. MLflow follows the redirect and returns the response body, which may contain temporary AWS credentials, Azure IMDS tokens, or internal service data.

python

 import urllib3
 from cachetools import TTLCache
 from packaging.version import Version
-from requests.adapters import HTTPAdapter
 from urllib3.util.retry import Retry
 
 from mlflow.entities.webhook import Webhook, WebhookEvent, WebhookTestResult

Source: MLflow patch commit ba949522. The patch replaces the default HTTPAdapter with a custom adapter that pins the validated address across redirects, closing the DNS-rebinding bypass.

Detection Methods for CVE-2026-64849

Indicators of Compromise

Outbound HTTP requests from MLflow servers to 169.254.169.254, metadata.google.internal, or 169.254.169.254/latest/meta-data/
Webhook test API calls (POST /api/2.0/mlflow/webhooks/{id}/test) originating from unauthenticated sources
DNS resolutions from MLflow hosts that return public addresses followed by rapid re-resolutions to private IP ranges
HTTP 3xx responses recorded in MLflow webhook delivery logs referencing redirect targets in RFC1918 or link-local ranges

Detection Strategies

Alert on any egress from MLflow application servers to cloud metadata IPs, which have no legitimate purpose from the webhook delivery process
Correlate MLflow webhook test invocations with subsequent internal HTTP traffic patterns
Monitor MLflow application logs for WebhookTestResult entries containing internal hostnames or private IPs in the resolved target

Monitoring Recommendations

Enable network flow logging on MLflow subnets and forward to a centralized analytics platform for baseline analysis
Instrument the MLflow reverse proxy to log full request paths and source IPs for /api/2.0/mlflow/webhooks/ endpoints
Configure IMDSv2 on AWS to require session tokens, making stolen metadata calls fail loudly and visibly in CloudTrail

How to Mitigate CVE-2026-64849

Immediate Actions Required

Upgrade MLflow to version 3.15.0 or later, which contains the fix from pull request #24258
Restrict network access to the MLflow REST API using network policies, reverse proxy authentication, or an identity-aware proxy
Rotate any cloud instance credentials associated with MLflow hosts if exploitation cannot be ruled out
Enforce IMDSv2 on AWS EC2 instances hosting MLflow to require token-bound metadata access

Patch Information

The fix is available in MLflow release v3.15.0. The patch pins the validated destination address across HTTP redirects in mlflow/webhooks/delivery.py and re-validates any redirect target before establishing the connection. Full technical context is available in the GitHub Security Advisory GHSA-7gwp-5pfp-969j and the upstream issue.

Workarounds

Disable or firewall the /api/2.0/mlflow/webhooks/ endpoints at the reverse proxy until the upgrade completes
Deploy MLflow behind an egress proxy that blocks connections to link-local, loopback, and private address ranges
Require authentication on all MLflow endpoints using an external auth proxy such as oauth2-proxy

bash

# NGINX example: block unauthenticated access to webhook test endpoint
location ~ ^/api/2\.0/mlflow/webhooks/.+/test$ {
    deny all;
    return 403;
}