MLflow unauthenticated webhook SSRF can expose internal and cloud metadata services

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.

• Package mlflow: the normalized CNA record identifies versions < 3.15.0 as affected.
• The clearest deployment scope is a self-managed MLflow Tracking Server with the model-registry webhooks API and a SQL store; the advisory states that the default mlflow server configuration with SQLite meets this condition.
• The CNA record and the fix narrative identify 3.15.0 as the fixed release.
• The current advisory page also displays <= 3.13.0 as the affected-version label and no patched-version entry, while its narrative still describes the issue as fixed in 3.15.0. Public material is therefore inconsistent for releases between the <= 3.13.0 and < 3.15.0 boundaries; the conservative remediation path is to upgrade to 3.15.0.

MLflow validates a webhook URL in mlflow/utils/validation.py by resolving the hostname and rejecting non-public IP addresses, but it does not pin the validated address to the actual connection. In mlflow/webhooks/delivery.py, the outbound HTTP request independently resolves the hostname and follows redirects by default, so the redirect target is not revalidated. An attacker can use a public HTTPS endpoint that passes the initial check and then redirects MLflow to a loopback address, private network service, or cloud metadata endpoint; DNS rebinding can also exploit the time-of-check to time-of-use gap between validation and connection. The POST /api/2.0/mlflow/webhooks/{id}/test endpoint returns the upstream response_status and response_body, making this path a full-read SSRF. The event-driven delivery path uses the same outbound mechanism and can provide blind SSRF; 307 or 308 redirects can preserve the POST method and body, creating a possible blind write to an internal service. The exact deployment exposure depends on Tracking Server reachability, availability of a SQL store for webhooks, and the authentication or reverse-proxy controls in use.

This vulnerability is reachable over the network against an MLflow Tracking Server. In the default configuration described by the advisory, the model-registry webhook API is unauthenticated, and /api/2.0/mlflow/webhooks/{id}/test can be invoked without user interaction. An attacker needs network access to the MLflow server and control of a public hostname or endpoint that can pass the initial URL check before using a redirect or DNS rebinding condition. The normalized record marks the issue as known exploited and as having a public exploit. The supplied evidence does not name a campaign, victim, or specific breach.

The flaw lets a request to MLflow make the server issue HTTP requests to internal, loopback, or cloud metadata destinations on the attacker's behalf. Because /test returns response_status and response_body, the result can be disclosure of resources visible to the MLflow server but not directly to the external client. Possible consequences include exposure of secrets, cloud credentials, internal service data, and network reconnaissance; the practical scope depends on the server's network position and credentials. A 307 or 308 redirect can also forward a POST to an internal service, creating an integrity impact that depends on the destination. The record does not establish a specific availability consequence or confirm compromise of a named organization.

• Data exposure: response bodies from internal services, administrative APIs, or cloud metadata may be returned to the attacker through the webhook test operation.
• Credential risk: if the server can reach cloud metadata, the response may contain credentials or tokens associated with the workload.
• Boundary bypass: the MLflow server can act as a network vantage point for resources that are not directly reachable by the attacker.
• Integrity risk: redirects that preserve POST can send attacker-controlled data to some internal services, although the result depends on the target endpoint and the server's privileges.
• The available evidence does not confirm a specific compromise, victim, or business loss.

1. Upgrade mlflow to 3.15.0, which the CNA record and fix narrative identify as addressing the issue. The fix adds SSRFProtectedHTTPAdapter, which validates the connected socket's peer IP at connection time before TLS or HTTP exchange and covers redirect targets.
2. If an upgrade cannot be completed immediately, restrict network access to the MLflow Tracking Server and place the webhook endpoints behind authentication or a controlled reverse proxy. This is a temporary compensating control, not a vendor-confirmed patch.
3. Restrict outbound access from the MLflow server to private, loopback, link-local, and cloud metadata networks according to least privilege. Verify that no configuration enabling private webhook IPs defeats the intended boundary.
4. Review access and outbound-connection logs for suspicious webhook tests or internal destinations; if metadata access may have occurred, investigate and rotate credentials or tokens that the server could use.
5. Because the current advisory display contains an inconsistent affected-version label, do not treat <= 3.13.0 as evidence that every release before 3.15.0 is safe.

• Inventory self-managed MLflow Tracking Servers, installed package versions, and webhook configuration; compare them with the version boundaries in affected_summary.
• Identify servers using the model-registry webhook API, a SQL store, and POST /api/2.0/mlflow/webhooks/{id}/test; verify whether authentication actually covers these endpoints.
• Review access and audit logs for unauthenticated requests to /api/2.0/mlflow/webhooks or /api/2.0/mlflow/webhooks/{id}/test, especially webhook creation followed by an immediate test request.
• Review egress telemetry from MLflow servers for connections to loopback, private, link-local, or cloud metadata addresses. This is a precautionary detection and investigation check, not a confirmed issue-specific IOC.
• If a server was reachable from an untrusted network, correlate webhook-test responses and unusual outbound connections during the same period; absence of log evidence does not prove that the system was safe.