MLflow SSRF CVE-2026-64849 Exploited: Cloud Credentials Stolen via Webhook Flaw

CVE-2026-64849 exploits a DNS rebinding bypass in MLflow's outbound webhook URL validation to reach cloud metadata services without any authentication. The attack chain requires no credentials and executes in seconds against an exposed server.

MLflow Tracking Servers expose a REST API for managing experiments, model registries, and webhooks. The POST /api/2.0/mlflow/webhooks/{id}/test endpoint fires a test delivery to a configured webhook URL and returns the response. MLflow's validation function, _validate_webhook_url(), calls the provided URL to check whether it resolves to an allowed address. The bug is in the delivery path: mlflow/webhooks/delivery.py follows HTTP redirects and re-resolves hostnames without pinning the IP address validated in the first step. An attacker controls a domain that returns a benign IP during the validation DNS lookup and the cloud metadata IP (169.254.169.254) during the delivery DNS lookup. MLflow validates the first resolution as safe, then makes the actual HTTP request to the metadata service using the second resolution.

AWS Instance Metadata Service at 169.254.169.254 provides temporary IAM credentials to any process on the EC2 instance. A successful MLflow SSRF attack returns those credentials in the HTTP response, including the AccessKeyId, SecretAccessKey, and SessionToken. Those credentials carry the IAM permissions of the attached instance profile, which in data science environments frequently includes broad S3 read/write access, SageMaker job execution, and Glue access. Equivalent metadata endpoints exist in Azure (169.254.169.254/metadata/identity/oauth2/token) and GCP (metadata.google.internal/computeMetadata/v1/instance/service-accounts/). The flaw bypasses any IP-based allowlist that operates only on the validation step and not on the delivery step. Organizations that block outbound connections from the MLflow server to 169.254.169.254 at the network layer are protected against credential exfiltration even on unpatched versions.

Attackers exploit the MLflow SSRF vulnerability to extract temporary cloud credentials from the metadata service, then use those credentials to exfiltrate data, deploy cryptominers, or establish persistent access through new IAM accounts before the short-lived token expires.

In confirmed incidents following the August 17 CVE assignment, attackers followed a consistent four-step playbook. First, automated scanners probed for internet-exposed MLflow Tracking Servers using Shodan, Censys, and direct HTTP GET requests to known MLflow API paths. Second, exploit payloads hit the /api/2.0/mlflow/webhooks/{id}/test endpoint using DNS rebinding payloads to reach 169.254.169.254. Third, the tool extracted temporary IAM credentials from the IMDS JSON response. Fourth, the attacker used those credentials to enumerate S3 bucket contents, spin up compute instances for cryptomining, and create new IAM users or access keys for durable persistence before the original short-lived credentials expired.

The credential theft is especially damaging for three reasons. The temporary credentials returned by IMDS are valid for up to six hours, providing a substantial window to establish persistence. Machine learning environments grant MLflow server instances broad cloud permissions because data scientists need access to training data in S3, model artifacts stored in object storage, and compute resources. The IAM permissions on a typical ML server instance are wider than those of a production web server. Organizations that run MLflow in shared data science platforms where the server has access to production data stores face the highest exposure.

Active exploitation of CVE-2026-64849 began within hours of CVE assignment on August 17, and CISA confirmed real-world impact when it added the vulnerability to the Known Exploited Vulnerabilities catalog on August 19, 2026.

watchTowr, the cybersecurity firm that tracked the post-disclosure exploitation wave, observed indiscriminate scanning for exposed MLflow Tracking Servers beginning within hours of the August 17 CVE assignment. The rapid shift from disclosure to active scanning reflects the automated tooling threat actors apply immediately to any SSRF vulnerability in a popular open-source platform where cloud credential exposure is the prize. MLflow Cloud deployments managed by Databricks are unaffected because Databricks applied the fix on the server side. Organizations running self-managed MLflow instances on AWS, Azure, or GCP are the target population.

The CISA KEV addition on August 19 confirmed that exploitation moved beyond scanning to confirmed cloud account compromise. CISA's standard for KEV inclusion requires evidence of actual exploitation in the wild, not merely the existence of a proof of concept. The mandatory federal remediation deadline of September 2, 2026 applies to all Federal Civilian Executive Branch agencies under Binding Operational Directive 26-04. Private organizations should treat September 2 as a hard target: the vulnerability is weaponized, the attack chain is fully automated, and the payoff for attackers scales with the number of exposed instances they can reach.

The runner-up threat this week is CVE-2026-25895, an unauthenticated file write leading to remote code execution in FUXA, an open-source OT SCADA HMI platform, under active scanning as of August 18 with roughly 60 publicly exposed instances. Defenders with FUXA deployments should apply the vendor patch immediately.

No specific attacker-controlled IP addresses, domains, or malware file hashes have been publicly disclosed for CVE-2026-64849. Detection relies on network telemetry, cloud audit log signals, and application access log patterns.

Network telemetry to monitor: outbound HTTP GET requests from the MLflow server process (python, gunicorn, uvicorn) to 169.254.169.254 or its Azure and GCP equivalents; POST requests to /api/2.0/mlflow/webhooks/ containing hostnames or redirect chains that resolve to RFC 1918 or link-local addresses; and anomalous outbound DNS queries from the MLflow server with very short TTL values (under five seconds) followed immediately by requests to a different IP than the one in the initial DNS response.

AWS CloudTrail signals that indicate post-exploitation activity: AssumeRoleWithInstanceProfile events originating from the MLflow server's instance at unexpected times or by unrecognized principals; ConsoleLogin events for IAM users created after August 19, 2026 from IPs not associated with your organization; CreateAccessKey events not correlated with a documented provisioning workflow; and RunInstances or SpotInstanceRequest events from the MLflow server's instance profile outside normal working hours.

MLflow application log indicators: POST entries to /api/2.0/mlflow/webhooks/{id}/test with webhook URLs containing raw IP addresses rather than hostnames; HTTP 200 responses to webhook test calls with response bodies significantly larger than a typical webhook test response (the IMDS credential JSON is approximately 500 bytes); and repeated test requests from the same source IP within a short window, consistent with automated scanning.

No CVE-specific community Sigma rule exists for CVE-2026-64849 yet. These rules were generated by Decryption Digest from the vulnerability's known behavior. Validate against your environment before production deployment. Both rules carry status: experimental.

Rule 1 targets web server access logs for POST requests to the MLflow webhook test endpoint. Any POST from an external IP to /api/2.0/mlflow/webhooks/ ending in /test is suspicious and warrants investigation; in environments where MLflow is not internet-facing this rule should fire rarely or never. Deploy this rule in your SIEM's web server log pipeline and alert immediately.

Rule 2 targets network connection logs for outbound connections from Python interpreter processes to 169.254.169.254. This is the direct indicator of a successful SSRF exploitation reaching the cloud metadata service. Any Python process connecting to this IP is either exploiting the vulnerability or is part of an unusual health check workflow. Treat this rule as high-confidence: set it to alert and page on-call.

Patching to MLflow 3.15.0 resolves the DNS rebinding bypass in the webhook URL validation. Credential rotation and IMDSv2 enrollment close the attack surface even before the patch is applied on instances where an immediate upgrade is not possible.

The MLflow SSRF vulnerability is part of a sustained wave of attacks against AI and machine learning infrastructure that accelerated through 2025 and 2026. Langflow, an open-source LLM orchestration platform, suffered an unauthenticated RCE via CVE-2026-9198 that gave attackers shell access on exposed servers. A LiteLLM supply chain attack exposed over 434,000 CI/CD pipeline credentials. CVE-2026-64849 fits the same pattern: ML platform infrastructure is internet-accessible by design, granted broad cloud permissions, and often excluded from enterprise security scanning because security teams categorize ML tooling as development infrastructure rather than production.

Three systemic factors amplify the risk. First, MLflow instances are commonly granted wide IAM permissions because data scientists need frictionless access to S3, SageMaker, and other cloud services. A compromised ML server is not just one server; it is a set of cloud IAM permissions that may touch production data stores. Second, MLflow deployments frequently bypass the hardening steps applied to production web servers: no WAF, no network segmentation from the internet, no security group restriction on the API port. Third, the attack requires zero victim interaction, scales with automation, and leaves no trace on the MLflow server itself once the attacker has the credential and deletes the test webhook entry.

The September 2 CISA deadline is the hard target, but the practical target is today. Automated exploitation of CVE-2026-64849 has been running for eight days as of August 25. Any exposed instance that has not been patched or had its metadata endpoint blocked has had eight days of exposure to systematic credential harvesting.