Critical MLflow SSRF vulnerability CVE-2023-XXXX exploited in the wild

Key Takeaways

• A critical unauthenticated Server-Side Request Forgery (SSRF) vulnerability, CVE-2026-64849, in MLflow is being actively exploited.
• The flaw affects all MLflow versions prior to 3.15.0 and carries a CVSS 3.1 score of 9.3.
• Exploitation allows attackers to harvest cloud credentials, sensitive deployment tokens, and access internal services.
• Adversaries began targeting vulnerable MLflow instances almost immediately after public disclosure.
• A patch is available in MLflow version 3.15.0, and immediate upgrades are advised, alongside post-exploitation mitigation steps.

Cybersecurity researchers have detected active exploitation of a severe, unauthenticated Server-Side Request Forgery (SSRF) vulnerability in MLflow, the widely adopted open-source platform for machine learning and data engineering workflows. This critical flaw, identified as CVE-2026-64849, enables threat actors to compromise internet-exposed MLflow instances, potentially leading to the exfiltration of sensitive cloud credentials and deployment tokens.

MLflow Vulnerability Details

The vulnerability, assigned a critical CVSS 3.1 score of 9.3, impacts all MLflow versions preceding 3.15.0. It stems from a design oversight in the default configuration of the MLflow Tracking Server, which, when initialized via mlflow server, operates without mandatory authentication and uses a local SQLite backend. This setup inadvertently exposes the model-registry webhooks API to untrusted network traffic.

The primary exploitation vector involves an unauthenticated POST request directed to the /api/2.0/mlflow/webhooks/{id}/test endpoint. While this endpoint’s intended function is to test designated webhooks, it critically reflects the full upstream HTTP status code and response body back to the attacker. This behavior transforms what would typically be a blind request forgery into a high-impact, full-read primitive, providing attackers with direct access to internal responses.

Although MLflow version 3.10.0 introduced the _validate_webhook_url() helper to block requests to private and cloud metadata addresses, this validation mechanism only scrutinizes the initial destination URL. The underlying delivery handler, located in mlflow/webhooks/delivery.py, subsequently follows HTTP redirects without re-validating the secondary address. This allows attackers to configure a publicly accessible endpoint that initially passes the validation checks, then issues an HTTP 302 redirect to internal resources such as link-local cloud metadata services or loopback interfaces. Furthermore, because hostname resolution occurs again after the initial allowlist verification, the system remains susceptible to DNS-rebinding attacks, a recurring architectural flaw seen in other machine learning framework SSRF bypasses.

In-the-Wild Exploitation Confirmed

watchTowr Cyber Intelligence reported that its global Attacker Eye honeypot sensor network observed adversaries targeting internet-exposed MLflow instances within hours of the public disclosure of CVE-2026-64849. Automated scanners rapidly began to exploit the vulnerability to harvest cloud credentials and sensitive deployment tokens, as confirmed by a tweet from August 18, 2026.

On major cloud providers like Amazon Web Services, Microsoft Azure, and Google Cloud Platform, the reflected response capability enables attackers to extract temporary IAM role credentials, OAuth tokens, and environment configurations directly from the link-local metadata address, typically http://169.254.169.254/. Beyond cloud provider metadata, the exploit can be leveraged to query internal microservices and administrative consoles that implicitly trust the host environment. The swiftness of these intrusions highlights a growing trend where automated tools quickly weaponize newly disclosed zero-click vulnerabilities against exposed enterprise infrastructure.

Patch and Mitigation

Maintainers have resolved the redirect and DNS-rebinding vulnerabilities in MLflow version 3.15.0 through pull request 24258. Organizations operating internet-facing or shared MLflow Tracking Servers must prioritize upgrading to version 3.15.0 or later immediately.

What You Should Do

• Upgrade MLflow: Immediately update all MLflow instances to version 3.15.0 or newer to patch the vulnerability.
• Audit Access Logs: Scrutinize access logs for any suspicious requests directed to /webhooks/*/test, which could indicate attempted or successful exploitation.
• Rotate Credentials: If MLflow instances were exposed, rotate all cloud IAM keys, OAuth tokens, and API secrets associated with those host instances.
• Enforce Egress Filtering: Implement network egress filtering to restrict unauthorized communication from MLflow hosts to link-local metadata addresses (e.g., 169.254.169.254) and other internal network segments.
• Implement Identity-Aware Proxies: Place MLflow Tracking Servers behind identity-aware proxies or secure gateways to ensure internal tracking portals are isolated from direct public internet exposure.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.