---
schema: 1
kind: vulnerability
title: "CVE-2026-64849 — MLflow: the SSRF guard resolves the webhook host and then throws the answer away, so one redirect turns an unauthenticated tracking server into a reader of its own cloud credentials"
headline: "CISA catalogued it as exploited on 19 August, and the default MLflow server needs no authentication to reach the webhook that does the fetching"
summary: >
  CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on 2026-08-19 with a 2026-09-02
  remediation date, recording confirmed exploitation of a server-side request forgery in MLflow. On a default
  MLflow tracking server the model-registry webhooks API is unauthenticated, including a test endpoint that
  returns the upstream response status and body to the caller. The URL guard resolves the webhook hostname and
  rejects non-public addresses at registration, but never pins the resolved address to the connection, and
  delivery follows HTTP redirects without re-validating where they lead — so a webhook pointed at an
  attacker-controlled public HTTPS host that answers with a redirect reaches internal and cloud instance-metadata
  services and reflects what it finds. Fixed in MLflow 3.15.0.
discovered_at: "2026-08-20T04:40:00Z"
event_date: "2026-08-19"
run_id: 2026-08-20T0409Z-intel
priority: high
immediate_action: null
tags: [vulnerabilities, info-disclosure, pre-auth, actively-exploited, cisa-kev, patch-available, cloud]
regions: [global]
sectors: [public-sector, finance, energy, healthcare, technology]
entities: []
techniques: [T1190, T1552.005]
affected_products: ["MLflow"]
cves:
  - id: CVE-2026-64849
    cvss: "9.3"
    epss: null
    type: ssrf
    vector: zero-click
    auth: pre-auth
    status: [exploited, cisa-kev, patch-available]
    affected: "MLflow before 3.15.0"
    fixed: "3.15.0"
sources:
  - url: "https://osv.dev/vulnerability/GHSA-7gwp-5pfp-969j"
    publisher: "GitHub Security Advisory GHSA-7gwp-5pfp-969j (read via the OSV.dev mirror)"
    date: "2026-08-17"
    role: primary
  - url: "https://github.com/mlflow/mlflow/pull/24258"
    publisher: "MLflow (fixing pull request)"
    date: "2026-07-02"
    role: corroborating
  - url: "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
    publisher: "CISA Known Exploited Vulnerabilities catalog"
    date: "2026-08-19"
    role: corroborating
closed_sources: []
evidence:
  - quote: "MLflow contains a server-side request forgery vulnerability that can allow attackers to reach internal or cloud metadata services and receive response_status and response_body."
    publisher: "CISA Known Exploited Vulnerabilities catalog"
  - quote: "The resolved IP is never carried into the connection."
    publisher: "GitHub Security Advisory GHSA-7gwp-5pfp-969j"
verification: multi-source
sourcing_note: >
  The exploitation determination rests on one authority — CISA's catalogue, read from the KEV JSON feed at
  catalogue version 2026.08.19, which names no exploiting cluster and describes no observed intrusion. The
  mechanism, the affected range and the fix come from the GitHub Security Advisory and its linked pull request;
  github.com refuses the transports available to this run, so the advisory was read through the OSV.dev mirror,
  which reproduces it in full and is cited as the reachable copy rather than as an independent assessor. The
  advisory records the flaw as confirmed live against MLflow 3.13.0 by the reporting researcher.
confidence: high
update_of: null
references: []
deep_dive: false
deep_dive_category: null
org_triage: null
classification:
  reliability: A
  credibility: 2
watchlist_hit: false
actions:
  - "Upgrade every MLflow tracking server to 3.15.0, which validates the peer address of the connected socket rather than the hostname at registration; where an upgrade has to wait, deny outbound traffic from the tracking-server host to link-local and RFC1918 destinations, because the reachable /test endpoint is what makes the server fetch on an attacker's behalf."
  - "Where an MLflow tracking server has been reachable from an untrusted network on a build below 3.15.0, treat the credentials its instance role or attached service account can mint as exposed and rotate them — the read primitive returns the metadata response body directly to the caller, so exposure does not require any further foothold."
migrated_from: null
---

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on 2026-08-19, with a remediation date of 2026-09-02, describing a server-side request forgery in MLflow "that can allow attackers to reach internal or cloud metadata services and receive response_status and response_body" (CISA Known Exploited Vulnerabilities catalog, version 2026.08.19). The remediation date is a US federal compliance clock and carries no weight here; the listing itself is what matters, because it is a government determination that this is being used against real deployments rather than a theoretical severity rating.

The mechanism is a guard that does its work and then discards the result. On a default MLflow tracking server — started with `mlflow server`, no authentication, the default SQLite backend — the model-registry webhooks API is reachable without credentials, and it includes a synchronous test endpoint that returns the upstream response status and body to whoever called it; the only webhook authorisation MLflow ships lives in an optional auth plugin that is not loaded by default ([GitHub Security Advisory GHSA-7gwp-5pfp-969j, 2026-08-17](https://osv.dev/vulnerability/GHSA-7gwp-5pfp-969j)). When a webhook is registered, the URL validator resolves the hostname and rejects any address that is not globally routable, which blocks the naive attempt to point a webhook at loopback or a metadata address. But, as the advisory puts it, "The resolved IP is never carried into the connection" ([GHSA-7gwp-5pfp-969j, 2026-08-17](https://osv.dev/vulnerability/GHSA-7gwp-5pfp-969j)) — delivery re-resolves the hostname independently and follows HTTP redirects without re-validating the redirect target. An attacker registers a webhook pointing at a public HTTPS host they control, which passes validation, and then fires the unauthenticated test endpoint; the host answers with a redirect to an internal or instance-metadata address, MLflow follows it, and the response body comes back in the test result. The same missing re-validation yields a second primitive: redirect status codes that preserve the method and body turn the same path into a blind write against internal management endpoints that act on POST. Neither requires authentication on a default open-source server, and the researcher confirmed the read primitive live against MLflow 3.13.0.

Detection sits in egress rather than on the application. The observable is the tracking-server host making outbound connections to link-local or private-range destinations — above all the cloud instance-metadata address — with the request originating from the MLflow process itself, and in web-access telemetry the preceding pair of unauthenticated requests that create a webhook and then call its test endpoint. **Triage:** a legitimate webhook target is operator-configured, stable, and resolves to the same external service every time; the discriminators are a webhook registered and tested within seconds of each other by an unauthenticated caller, and a delivery attempt whose final destination is inside the network the server sits in rather than the host that was registered. Neither is a normal shape for a notification integration.

**Defender takeaway:** the fix in 3.15.0 moves validation to connection time, checking the peer address of the socket actually opened rather than trusting a hostname resolved earlier ([MLflow pull request 24258, merged 2026-07-02](https://github.com/mlflow/mlflow/pull/24258)); the advisory records that this closes the redirect-follow path as well as the rebinding race ([GHSA-7gwp-5pfp-969j, 2026-08-17](https://osv.dev/vulnerability/GHSA-7gwp-5pfp-969j)). Until that upgrade lands, the load-bearing control is egress from the tracking-server host, not authentication in front of it — the flaw is that the server itself is willing to fetch. This is also a reminder about where machine-learning platform infrastructure sits in an estate: MLflow is commonly stood up by data-science teams on cloud instances with roles attached, outside the review that a public-facing application would get, and its default posture is no authentication at all.