MLflow Server-Side Request Forgery Vulnerability

🚨SEVERITY: CRITICAL — CVSS 9.3Security Advisory

TL;DR 📌

  • 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…
  • Highest CVSS: 9.3 (Critical).
  • Listed in CISA KEV (2026-08-19) — this is being exploited in the wild.
  • Fixed in 3.15.0 — upgrade to this release or later.
  • CVEs: CVE-2026-64849.

What it is

CVE-2026-64849 is a server-side request forgery vulnerability in MLflow’s webhook testing feature. The flaw sits in the POST /api/2.0/mlflow/webhooks/{id}/test endpoint, which is unauthenticated.

MLflow validates the target URL of a webhook via _validate_webhook_url() in mlflow/utils/validation.py before issuing the test request. The problem is that this check only runs against the original URL supplied. The actual request delivery, handled in mlflow/webhooks/delivery.py, follows HTTP redirects and re-resolves the hostname at each hop, without pinning the connection to the address that was validated. An attacker can therefore point the webhook test at a URL that passes validation, then redirect the request to an internal address or a cloud metadata endpoint that would otherwise be blocked.

Because the endpoint returns response_status and response_body from the redirected request, the attacker gets the response content back directly, effectively using the MLflow server as a proxy to read from internal services or metadata endpoints it can reach on the network.

The access path requires no authentication and no user interaction — a single unauthenticated POST request over the network is sufficient, which accounts for the CVSS score of 9.3 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N).

What to do

  • Upgrade MLflow to 3.15.0, which fixes the redirect-following flaw by validating (or re-validating) the resolved address rather than just the original URL.
  • This CVE is listed in CISA’s KEV catalogue (added 2026-08-19); treat patching as time-sensitive rather than routine maintenance.
  • Until upgraded, restrict network access to the MLflow server’s API, particularly the webhook management endpoints, and block or firewall outbound access from the MLflow host to internal metadata services and other sensitive internal ranges.
  • Review MLflow webhook configurations and server logs for test calls to unexpected or internal-looking URLs, and check for prior use of the /webhooks/{id}/test endpoint that returned response bodies from unfamiliar targets.

For leadership 🧭

Executive summary. An unauthenticated attacker can abuse MLflow’s webhook test feature to reach internal systems or cloud metadata endpoints and read the response, with no login or user action required. This is already listed in CISA’s KEV catalogue, so it should be treated as an active, time-sensitive risk rather than routine patching.

Why it matters:

  • The POST /api/2.0/mlflow/webhooks/{id}/test endpoint requires no authentication, so anyone who can reach the MLflow server over the network can trigger the flaw.
  • URL validation only checks the original address; the actual request in mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname, so a validated URL can redirect to internal IPs or cloud metadata services.
  • The endpoint returns response_status and response_body to the caller, turning the MLflow server into a proxy that hands back the contents of whatever internal or metadata endpoint it reaches.
  • CVSS 9.3 with no privileges or user interaction needed reflects that this is a direct, remotely triggerable path into internal network resources.

Now / Next / Later:

  • Now: Restrict network access to the MLflow server’s API, especially the webhook management and test endpoints, and block outbound access from the MLflow host to metadata services and other sensitive internal ranges until patched.
  • Next: Upgrade MLflow to 3.15.0, which fixes the flaw by validating the resolved address used for delivery rather than only the originally supplied URL.
  • Later: Review webhook configurations and server logs for past test calls to unexpected or internal-looking URLs, and build a check for this class of redirect-validation gap into future webhook or callback features.

Source