AIDEFEND in Action AIA-0066 Incident Published: Aug 24, 2026

MLflow Webhook Redirects Turn a Public URL into Full-Read SSRF

CVE-2026-64849 affects MLflow >= 3.10.0, < 3.15.0; the official patched version is 3.15.0. On a default Tracking Server, webhook management and the synchronous test endpoint are unauthenticated. An attacker can register a public HTTPS webhook, trigger its test, and return a 302 redirect to a loopback, private-network, or cloud-metadata URL. MLflow validates only the original hostname, follows the redirect without validating or pinning the destination, and reflects the internal response body. CISA added the CVE to KEV on August 19, 2026; the catalog does not identify the exploitation details.

Credential ExposureData ExfiltrationInput ValidationSystem-Level DefenseAI Infrastructure
4 applicable AIDEFEND defenses
Source: Unauthenticated full-read SSRF in MLflow webhook delivery (GHSA-7gwp-5pfp-969j) 
Authors: freeman-bb (original private report); AUTHENSOR (independent discovery)
Original article: Aug 2, 2026

Threat Analysis

  • The initial URL check was separated from the connection that mattered. _validate_webhook_url() resolved and rejected non-public addresses, but the validated address was not pinned to delivery. Each redirect or later connection could resolve to a different destination.
  • The default authorization boundary was absent. The open-source default server does not load the optional auth plugin, so an unauthenticated caller can create a webhook and invoke /api/2.0/mlflow/webhooks/{id}/test.
  • A 302 creates a readable SSRF primitive. The attacker-controlled HTTPS endpoint redirects MLflow to an internal target; the test API returns the upstream status and body. The advisory demonstrates a local secret service and identifies cloud instance metadata and internal admin services as reachable targets.
  • The official patched version is 3.15.0. PR #24258 adds connection-time peer validation, including redirect targets. The released 3.15.0 source uses SSRFProtectedHTTPAdapter for both HTTP and HTTPS. Deploy the verified fixed artifact and test the actual running population; upgrading does not enable API authentication by itself.

Applicable AIDEFEND Defenses (4)

AID-H-019.001
URL Normalization & Allowlist Filtering
Very High
Use a fail-closed safe fetcher that validates every redirect target, connects only to the freshly validated public IP, and binds the decision to the final URL and returned bytes. This directly closes both redirect and DNS-rebinding TOCTOU paths.
AID-H-004.002
Service & API Authentication
High
Require authenticated, short-lived credentials for webhook creation and test operations. Enforce caller authentication on the server-side API path rather than relying on network reachability or the optional default-disabled plugin.
AID-I-002.001
Internal AI Network Segmentation
High
Apply least-privilege internal network policy so the MLflow workload cannot reach instance metadata, loopback-admin bridges, or unrelated private services even if application URL validation fails.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
High
Deploy the official 3.15.0 fix, or a later release verified to contain it, through a rebuilt immutable artifact, bounded canary, staged rollout and rollback probes. Independently read back every running MLflow digest and test 302 redirects and DNS rebinding before closing the finding. A release announcement or package download is not proof of deployment; retain verified compensating controls until the affected fleet is remediated.

What Defenders Should Do Now

  • Inventory MLflow Tracking Servers >= 3.10.0, < 3.15.0 and identify which expose webhook APIs to untrusted networks.
  • Enable an authentication layer and deny unauthenticated webhook create, update, delete, and test calls.
  • Deploy a verified release containing the 3.15.0 fix and confirm every running instance. Until deployment is complete, disable webhooks where possible or place the server behind a restrictive gateway; block workload access to link-local metadata, loopback management services, and unrelated private networks.
  • Review webhook URLs, redirect telemetry, and test responses for attacker-controlled public hosts followed by private or link-local destinations.
  • If internal or metadata access may have occurred, treat returned secrets as exposed and rotate them; do not infer theft solely from product exposure.

Conclusion

The failure is a classic validation-to-use gap made more severe by an unauthenticated, body-reflecting test API. The durable fix is connection-time destination enforcement for every hop, paired with API authentication and network least privilege. CISA KEV raises remediation urgency but does not justify unsupported claims about victims, payloads, or stolen credentials.

Last updated: