CVE-2026-64849 in Mlflow
Summary
by MITRE • 08/17/2026
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. Prior to 3.15.0, the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint calls _validate_webhook_url() in mlflow/utils/validation.py only for the original URL while mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without pinning the validated address, allowing attackers to reach internal or cloud metadata services and receive response_status and response_body. This issue is fixed in version 3.15.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in MLflow versions prior to 3.15.0 represents a critical server-side request forgery flaw rooted in inconsistent input validation logic within the webhook testing mechanism. MLflow serves as an open-source platform for managing machine learning lifecycles, and its API includes endpoints designed for administrative tasks such as configuring webhooks that notify external services about experiment events. The specific endpoint affected is POST /api/2.0/mlflow/webhooks/{id}/test, which allows users to test a configured webhook by sending a sample payload to the specified URL. While this functionality is intended for legitimate operational testing, the implementation contains a significant security oversight regarding how URLs are validated and subsequently accessed during the request execution phase.
The core technical flaw lies in the discrepancy between the validation step and the actual network communication step. When a user submits a webhook URL via the test endpoint, the system invokes _validate_webhook_url() from mlflow/utils/validation.py to check if the provided address is permissible based on predefined allowlists or blocklists. This function performs an initial security check against the original hostname supplied by the user. However, when the actual HTTP request is dispatched through mlflow/webhooks/delivery.py, the library used for making requests follows HTTP redirects automatically. Crucially, after following a redirect to a new location, the system re-resolves and connects to the final destination without applying the same validation constraints that were applied to the initial URL. This lack of persistent pinning means that if an attacker provides a malicious domain that redirects to an internal IP address or a cloud metadata service endpoint, the server will accept the redirect and send the request there, effectively bypassing the original security checks.
This architectural weakness enables attackers to perform Server-Side Request Forgery attacks against internal infrastructure services that are not directly exposed to the public internet but are accessible from within the network segment where MLflow is deployed. By leveraging HTTP redirects, an attacker can trick the MLflow server into making requests to sensitive endpoints such as AWS EC2 instance metadata service at 169.254.169.254, Azure managed identity endpoints, or internal Kubernetes API servers. The impact of this vulnerability extends beyond mere network access; because the test endpoint returns the response status and body back to the requester in its JSON payload, it creates a classic SSRF amplification vector known as blind SSRF with data exfiltration capabilities. Attackers can not only probe for open ports or service banners but also extract sensitive configuration details, authentication tokens, and other confidential data stored on internal metadata services through the response body returned by MLflow.
From a classification perspective, this vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where server-side code makes requests to user-supplied URLs without proper validation of redirects or final destinations. It also maps closely to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Movement via SSRF, as the attacker uses the compromised application as a proxy to interact with internal resources that would otherwise be unreachable from their external position. The failure to pin the validated address after redirect resolution is a common pattern in web applications that utilize HTTP clients like Python's requests library without disabling automatic redirects or implementing strict post-redirect validation logic.
To mitigate this vulnerability, organizations running MLflow versions prior to 3.15.0 must upgrade immediately to version 3.15.0 or later, where the developers have addressed the issue by ensuring that the validated address is pinned throughout the entire request lifecycle, including after any redirects occur. For environments where upgrading is not immediately feasible, temporary mitigations include restricting outbound network traffic from MLflow servers using firewall rules to block access to internal metadata service IP ranges and private subnets. Additionally, configuring the webhook delivery mechanism to disable automatic HTTP redirect following can prevent attackers from leveraging redirection chains to bypass validation checks. It is also advisable to implement strict allowlists for permitted external domains in the application configuration rather than relying solely on blacklist-based validation, which is inherently more susceptible to evasion techniques such as DNS rebinding or redirect chaining.