MLflow - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/mlflow/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 18 Aug 2026 00:46:13 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgMLflow Tracking Server Unauthenticated Full-Read SSRF via Webhook Deliveryhttps://feed.craftedsignal.io/briefs/2026-08-mlflow-ssrf/Tue, 18 Aug 2026 00:46:13 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-08-mlflow-ssrf/MLflow Tracking Server versions prior to 3.15.0 are vulnerable to an unauthenticated full-read SSRF attack because the webhook delivery mechanism follows unvalidated HTTP redirects, allowing attackers to exfiltrate internal data or interact with local services.MLflow Tracking Server (v3.13.0 and earlier) contains an SSRF vulnerability (CVE-2026-64849) in its webhook delivery mechanism. While the application implements a validation function (_validate_webhook_url) intended to restrict connections to public IP addresses, the implementation fails to pin the resolved IP address, and the HTTP client follows redirects without re-validating the final destination. An unauthenticated attacker can create a webhook pointing to a controlled HTTPS endpoint that issues a 302 redirect to internal network resources, such as the AWS Instance Metadata Service (169.254.169.254) or loopback addresses. Because the synchronous /api/2.0/mlflow/webhooks/{id}/test endpoint reflects the response status and body back to the caller, this allows for unauthenticated full-read exfiltration of sensitive internal data or blind POST interactions with management interfaces on the local network.

Attack Chain

  1. Attacker identifies an internet-facing MLflow Tracking Server instance running with a default configuration (e.g., SQLite backend) lacking authentication plugins.
  2. Attacker prepares a malicious HTTPS-enabled server that returns a 302 HTTP redirect to an internal target (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/).
  3. Attacker submits a POST request to /api/2.0/mlflow/webhooks with the url parameter pointing to the malicious attacker-controlled HTTPS endpoint.
  4. MLflow validates the initial URL; since the attacker's endpoint is a valid public HTTPS URL, the _validate_webhook_url check passes.
  5. Attacker triggers the SSRF by sending a request to the /api/2.0/mlflow/webhooks/{id}/test endpoint.
  6. The MLflow server executes the webhook, follows the 302 redirect to the internal target without re-validation, and fetches the sensitive internal resource.
  7. The server receives the internal response (e.g., cloud credentials) and reflects the full response body back to the attacker in the HTTP response of the /test request.

Impact

Successful exploitation allows unauthenticated attackers to exfiltrate sensitive cloud metadata (e.g., IAM role credentials), query internal-only services, or perform host scanning from the perspective of the MLflow server. Furthermore, by using 307 or 308 redirects, attackers can perform blind POST operations against internal management interfaces like Docker daemons or Spring Boot Actuator endpoints, potentially leading to remote code execution or service disruption within the internal network.

Recommendation

Prioritize the following actions to secure your MLflow environment:

  • Upgrade MLflow to version 3.15.0 or later immediately to patch CVE-2026-64849.
  • Enable MLflow authentication plugins to ensure that the webhook API is not accessible to unauthenticated users.
  • Implement network segmentation to isolate MLflow servers from sensitive cloud metadata endpoints (IMDSv1) and internal management interfaces.
  • Deploy the suggested webserver-level rules to detect potential SSRF attempts directed at common internal paths.
]]>criticaladvisoryssrfmlflowweb-vulnerability