CVE-2026-64849 — MLflow Server-Side Request Forgery (SSRF) Vulnerability in Model Registry Webhooks

CVE-2026-64849 (TL-2026-2077) is a critical-severity software vulnerability scored CVSS 9.3, first published 2026-08-19. It has no confirmed attribution, affects LF Projects (MLflow) MLflow Tracking Server, references 1 CVE (CVE-2026-64849), maps to 12 MITRE ATT&CK techniques (T1046, T1071.001, T1190), and is covered by 9 detection rules and 10 indicators of compromise.

Key facts for TL-2026-2077

Threat ID
TL-2026-2077
Severity
CRITICAL
CVSS
9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N)
Status
ACTIVE
Category
VULNERABILITY
First published
2026-08-19
Last reviewed
2026-08-19
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
technology, ai-ml, cloud-computing, finance, health, government administration, research, ecommerce
Target regions
Global
Detection rules
9
Indicators of compromise
10

Malware and tooling in CVE-2026-64849

Malware and tooling: Interactsh, Shodan

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on August 19, 2026, confirming active exploitation. The vulnerability is an unauthenticated full-read SSRF in MLflow (prior to v3.15.0) that allows attackers to reach internal services or cloud metadata endpoints via HTTP redirect following (302/307/308) and DNS rebinding TOCTOU bypasses of the webhook URL guard. watchTowr detected indiscriminate scanning for exposed MLflow instances within hours of CVE assignment, with attackers specifically targeting cloud metadata services to exfiltrate IAM credentials and service account tokens across AWS, GCP, and Azure environments.

How CVE-2026-64849 works

CVE-2026-64849 is a critical unauthenticated Server-Side Request Forgery (SSRF) vulnerability in MLflow's model-registry webhooks API, affecting all versions prior to 3.15.0. The default MLflow Tracking Server (started via `mlflow server`, binding to 0.0.0.0 with no authentication plugin by default) exposes the unauthenticated `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint, which synchronously delivers webhook payloads and reflects the upstream response status and body back to the caller.

A previous SSRF guard (`_validate_webhook_url`) was added in PR #20747 (shipped in MLflow 3.10.0) to fix CVE-2026-2393. This guard resolved the webhook hostname via `socket.getaddrinfo()` and rejected non-public IPs using `ip.is_global`. However, the fix was incomplete — the resolved IP was never pinned or carried forward to the actual connection, creating a critical time-of-check/time-of-use (TOCTOU) gap.

Two distinct bypass vectors exist. First, the webhook delivery code (`mlflow/webhooks/delivery.py`) follows HTTP redirects without `allow_redirects=False` and never re-validates the redirect target. An attacker hosts a public HTTPS endpoint that passes the IP validation check, then returns a 302 redirect to an internal URL such as `http://169.254.169.254/latest/meta-data/iam/security-credentials/`. MLflow follows the redirect and reflects the response body (containing cloud IAM credentials) back to the attacker. With 307/308 redirects, the POST method and body are preserved, enabling blind writes to internal management endpoints such as Docker daemon `/stop`, Elasticsearch `/_close`, or Spring Boot Actuator `/shutdown`. The first hop must be HTTPS (the default allowed scheme), but the redirect Location may be HTTP.

Second, a DNS rebinding TOCTOU attack exploits the fact that `_validate_webhook_url` resolves the hostname independently from the subsequent `session.post(webhook.url)` call. An attacker-controlled DNS server returns a public IP during validation (passing `ip.is_global`), then switches to a private IP (e.g., 169.254.169.254) when the actual HTTP request resolves the hostname again. The existing `TrustedHostMiddleware` from PR #22095 was never applied to outbound webhook delivery. Default settings `_MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS=False` and `_MLFLOW_WEBHOOK_ALLOWED_SCHEMES=["https"]` do not prevent the rebinding attack since they operate at validation time, not at connection time.

The fix (PR #24258, commit ba94952247, shipped in MLflow 3.15.0) introduces an `SSRFProtectedHTTPAdapter` that validates the peer IP of each connected socket immediately after `connect()` and before any TLS/HTTP exchange. This covers redirect targets (each redirect opens a new connection through the protected pool) and closes both redirect-following and DNS-rebinding TOCTOU variants. The adapter also sets `trust_env=False` and overrides `proxy_manager_for` to prevent proxy bypass via `HTTP(S)_PROXY` environment variables.

watchTowr's global honeypot network detected indiscriminate scanning for exposed MLflow instances within hours of CVE assignment on August 17, 2026. Attackers are specifically targeting cloud-hosted MLflow systems and exfiltrating cloud credentials and secrets (IAM credentials, service account tokens). Shodan data indicates approximately 25,000+ publicly accessible MLflow instances, with ~740 confirmed via banner verification, and approximately 4,000+ accessible without authentication — making MLflow one of the most reliably identifiable and exposed AI tracking services. A prior coordinated exploitation campaign (GitHub issue #23500) exploiting CVE-2023-6831 and CVE-2023-42364 found 238 exposed instances with 103 confirmed compromised. No specific threat actor group has been publicly attributed to CVE-2026-64849 exploitation at this time.

CISA's SSVC assessment shifted from `exploitation:none` to `exploitation:active` on August 19, 2026, with `automatable:yes` and `technicalImpact:total`. CISA requires remediation by September 2, 2026 per BOD 26-04 guidance. The EPSS score is 1.1% (30-day), reflecting early-but-active exploitation primarily targeting high-value cloud environments rather than broad opportunistic attacks.

MITRE ATT&CK techniques used in TL-2026-2077

Discovery

T1046 Network Service Discovery

Command and Control

T1071.001 Web Protocols

Initial Access

T1190 Exploit Public-Facing Application

Impact

T1496 Resource Hijacking; T1529 System Shutdown/Reboot

Credential Access

T1552.005 Unsecured Credentials: Cloud Instance Metadata API

Resource Development

T1583.001 Acquire Infrastructure: Domains; T1583.002 Acquire Infrastructure: DNS Server; T1588.006 Obtain Capabilities: Vulnerabilities

Reconnaissance

T1595 Active Scanning; T1595.001 Scanning IP Blocks; T1595.002 Vulnerability Scanning

Affected products and versions in CVE-2026-64849

  • LF Projects (MLflow) — MLflow Tracking Server
    Vulnerable versions: All versions prior to 3.15.0 (confirmed vulnerable through 3.13.0)
    Fixed in: 3.15.0

Remediation for CVE-2026-64849

Patches

  • Upgrade to MLflow 3.15.0 (PR #24258, commit ba94952247)
  • Enable MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS is NOT a security measure — it is a development escape hatch

Immediate actions

  • Upgrade MLflow to version 3.15.0 or later immediately — contains SSRFProtectedHTTPAdapter with connection-time IP validation
  • Restrict network access to MLflow Tracking Servers — do not expose to the public internet without authentication
  • Enable MLflow's optional authentication plugin on all tracking server deployments
  • Block outbound requests from MLflow servers to cloud metadata endpoints (169.254.169.254, metadata.google.internal, 169.254.169.254/metadata/instance) where not needed
  • Review audit logs for suspicious webhook creation and test API requests to /api/2.0/mlflow/webhooks/

Workarounds

  • Disable the model-registry webhooks feature entirely if not in use
  • Deploy a WAF with SSRF rules blocking outbound requests to 169.254.169.254 and other link-local addresses
  • Apply network-layer egress filtering from MLflow server subnets to cloud metadata endpoints
  • Use IMDSv2 on AWS which requires token-based access less susceptible to simple SSRF

Longer-term hardening

  • Implement network segmentation — MLflow servers should reside in isolated VPCs with strict egress controls
  • Deploy reverse proxy with SSRF filtering (e.g., squid with SSL bump) in front of MLflow tracking servers
  • Implement cloud-side IMDSv2 with hop limit enforcement (AWS IMDSv2 required-token headers prevent SSRF credential theft)
  • Rotate all cloud credentials (IAM keys, service account tokens) if an MLflow server was exposed during the vulnerability window
  • Add behavioral monitoring rules for outbound HTTP redirect chains originating from MLflow servers
  • Conduct incident response triage for any exposed MLflow instances to assess whether credential compromise occurred

CVEs associated with CVE-2026-64849

CVE-2026-64849

Weaknesses (CWE) in CVE-2026-64849

CWE-918

Timeline of CVE-2026-64849

  • CVE-2025-14279 published: MLflow DNS rebinding via missing Origin header validation (CVSS 8.1), fixed in MLflow 3.5.0 — precursor vulnerability in the same attack class (DNS-rebinding SSRF)
  • PR #20747 merged by TomeHirata, shipped in MLflow 3.10.0 — first SSRF guard _validate_webhook_url() added, resolving hostname and rejecting non-public IPs; this guard created the TOCTOU gap later exploited by CVE-2026-64849
  • CVE-2026-2393 published: Authenticated SSRF in MLflow webhooks (<3.9.0, CVSS 7.1) — original vulnerability that prompted the _validate_webhook_url guard. Confirms SSRF was a known attack surface in MLflow webhooks prior to CVE-2026-64849
  • GitHub Issue #23500 documents coordinated exploitation campaign targeting unauthenticated MLflow model registration APIs — 238 exposed instances confirmed, 103 servers showed indicators of compromise including DNS callback payloads and Interactsh probes — leveraging CVE-2023-6831 and CVE-2023-42364
  • CVE-2026-64849 initially reported privately to the MLflow security team by researcher freeman-bb, describing the DNS-rebinding and redirect-following bypasses of the _validate_webhook_url guard
  • GitHub Issue #24179 independently published by researcher AUTHENSOR with full reproduction PoC — DNS rebinding SSRF bypass with specific exploit script targeting AWS IMDS at 169.254.169.254. Additional finders credited: y011d4, ibondarenko1, h1-mrz, th3cyb3rc0p
  • PR #24258 merged (commit ba94952247) by PattaraS — SSRFProtectedHTTPAdapter added with connection-time IP validation, trust_env=False, and proxy_manager_for override. Closes redirect-following (302/307/308) and DNS-rebinding TOCTOU variants simultaneously
  • watchTowr global honeypot network detects indiscriminate scanning for exposed MLflow instances within hours of CVE assignment on August 17, 2026. Attackers specifically targeting cloud-hosted MLflow systems with payloads aimed at 169.254.169.254 (cloud metadata endpoints) to exfiltrate IAM credentials and service account tokens
  • CVE-2026-64849 officially assigned by GitHub CNA. GHSA-7gwp-5pfp-969j published with CVSS 9.3 (CRITICAL). Advisory details both bypass vectors and confirms the fix in PR #24258
  • VulnCheck independently confirms active scanning for MLflow SSRF targets. Combined campaign targeting both MLflow (CVE-2026-64849) and FUXA (CVE-2026-25895, CVE-2026-25939) vulnerabilities — FUXA scanning attributed to a single IP address broadly scanning the internet
  • The Hacker News and SecurityOnline publish coverage of active MLflow SSRF exploitation, quoting watchTowr Principal Threat Intelligence Specialist Yordan Ganchev. CISA KEV inclusion widely reported. CISA BOD 26-04 remediation deadline set for September 2, 2026
  • MLflow 3.15.0 released officially including SSRFProtectedHTTPAdapter fix. Release notes also document additional security hardening: artifact authorization enforcement on presigned download routes, permission enforcement on model version creation, LogInputs authorization, pickle deserialization guard (MLFLOW_ALLOW_PICKLE_DESERIALIZATION), and workspace context resolution for FastAPI auth validators
  • CISA adds CVE-2026-64849 to Known Exploited Vulnerabilities Catalog with due date September 2, 2026. CISA SSVC assessment: exploitation:active, automatable:yes, technicalImpact:total. Required action per BOD 26-04: apply mitigations per vendor instructions or discontinue use

Sources cited for CVE-2026-64849

Threats related to CVE-2026-64849

Detection coverage for TL-2026-2077

As of 2026-08-19, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2077 across Splunk SPL, Microsoft KQL and Sigma, covering 10 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats