What happened
MLflow published GHSA-7gwp-5pfp-969j on August 2, 2026, documenting unauthenticated full-read server-side request forgery in webhook delivery. CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalogue on August 19, 2026. MLflow versions below 3.15.0 are affected by CVE-2026-64849; version 3.15.0 contains the fix. The CISA listing requires US federal civilian agencies to secure affected MLflow instances within two weeks under BOD 26-04.
The affected agent or framework is MLflow, specifically the self-hosted MLflow Tracking Server. No underlying AI model or model version is involved or identified in the cited sources. The vulnerable operator configuration is a reachable MLflow Tracking Server using the model-registry webhooks API; the default OSS deployment has no authentication. The server mechanically follows attacker-controlled redirects and returns internal response bodies through POST /api/2.0/mlflow/webhooks/{id}/test.
The default MLflow Tracking Server exposes POST /api/2.0/mlflow/webhooks/{id}/test without authentication and returns the upstream response status and body. A 302 redirect can expose responses from targets such as 169.254.169.254, while 307 or 308 redirects can preserve attacker-controlled POST requests to internal services. Fix commit ba94952247 adds SSRFProtectedHTTPAdapter to validate the connected peer IP before TLS or HTTP exchange and on each redirected connection.
CISA did not publish attacker IP addresses, domains, hashes, victim counts or a detailed exploitation timeline. Attribution posture: CISA and the MLflow advisory name no actor for the observed exploitation. The absence of published indicators means defenders must rely on local asset, webhook, network and cloud-audit evidence rather than a denylist.
Why this matters now
MLflow commonly sits close to models, experiment data, artefact stores, cloud identities and internal engineering services. The flaw allows an unauthenticated remote party to make the Tracking Server reach internal or metadata endpoints and return response content. Consequently, the business risk is not limited to the MLflow service: instance-role credentials or access to private management interfaces can extend the incident into the surrounding cloud environment.
The KEV listing materially changes prioritisation because exploitation is no longer theoretical. Patching closes the vulnerable request path but cannot establish whether credentials or internal responses were previously exposed. Organisations using default or internet-reachable self-hosted deployments need a retrospective webhook and cloud-audit review, followed by credential containment wherever historical evidence is incomplete.
The decision for security leaders
Assign vulnerability management and MLOps owners to produce a decision-grade inventory that distinguishes embedded MLflow client libraries from reachable Tracking Server deployments. Prioritise servers with public ingress, default authentication behaviour, SQL-backed webhook functionality or broad cloud roles. Where immediate upgrading is unsafe, remove untrusted reachability and disable the vulnerable path under a time-bound exception.
Run patching and compromise assessment as parallel workstreams. Review webhook creation, testing and deletion events; inspect outbound requests from MLflow hosts; identify access to metadata and internal management services; and examine subsequent cloud activity under the instance role. Rotate credentials where logs are absent, incomplete or show suspicious access, because upgrade status alone cannot close prior exposure.
Evidence of closure
- Asset records show no reachable MLflow version below 3.15.0.
- Configuration testing confirms unauthenticated webhook creation and test calls are blocked.
- Log review documents the disposition of every suspicious webhook operation.
- Cloud credential-rotation records cover every potentially exposed instance role and inspect cloud activity before declaring closure.
The Security.io assessment
The KEV addition is authoritative evidence that exploitation has occurred, but it does not establish that every exposed MLflow server was compromised or that cloud credentials were stolen in each case. The vulnerability’s mechanics nevertheless make credential impact plausible wherever a vulnerable server could reach metadata services. Claim strength should follow local evidence from webhook activity, network flows and cloud control-plane logs.
This issue also exposes a recurring MLOps governance gap: experimental platforms can acquire production-grade network reach and cloud privilege without corresponding authentication, inventory or monitoring. The durable control is not simply keeping MLflow current. It is treating AI engineering control planes as privileged applications, constraining their identities and egress, and requiring security ownership before they can reach sensitive internal services.
Questions for the morning meeting
- Which MLflow Tracking Server instances are reachable from untrusted networks?
- Do any reachable instances run a version below 3.15.0?
- Which cloud roles and internal services are accessible from each MLflow host?
- Can teams distinguish legitimate webhook testing from exploitation attempts in retained logs?