What happened
MLflow published GHSA-7gwp-5pfp-969j on August 2, 2026, and the GitHub Advisory Database recorded CVE-2026-64849 on August 17, 2026. MLflow versions before 3.15.0 are affected; version 3.15.0 contains the fix. The vulnerability is an unauthenticated server-side request forgery in webhook delivery, where the original destination is validated but subsequent redirects or DNS resolution can reach internal addresses.
On August 19, 2026, CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalogue based on evidence of active exploitation. The unauthenticated path uses POST /api/2.0/mlflow/webhooks to create a webhook and POST /api/2.0/mlflow/webhooks/{webhook_id}/test to trigger a server-side request whose response can be reflected. HTTP 302 redirects enable full-read requests, while 307 or 308 redirects can preserve POST requests into private-network services.
An attacker can target AWS instance metadata at 169.254.169.254 or internal services reachable from the MLflow server. The fix is associated with pull request 24258 and commit ba94952247. The implementation adds connection-time peer-IP validation so redirect targets and DNS-rebinding attempts are checked before application data is exchanged.
The affected framework is MLflow, an open-source AI engineering platform for agents, large language models and machine-learning models. No underlying AI model or model version was identified in the cited sources. No AI operator configuration was identified; exploitation targets the MLflow tracking server’s webhook implementation. The server mechanically follows attacker-controlled redirects and can return internal response content through the webhook test result. Attribution posture: CISA confirmed active exploitation of CVE-2026-64849 but neither CISA nor the MLflow advisory named an actor or victim organisation. The cited sources did not publish exploit-campaign IP addresses, domains, victim names or a verified compromise count.
Why this matters now
CISA’s exploited-vulnerability determination changes the decision from routine upgrade planning to incident-aware remediation. An organisation that patches without examining historical webhook activity may close the software exposure while leaving stolen cloud credentials, accessed internal data or attacker-created webhooks unaddressed.
The vulnerable component sits inside an AI and machine-learning engineering workflow but can reach beyond that boundary. Server-side requests originate from the MLflow host’s network position, potentially exposing cloud instance metadata, administrative services and internal applications that were never designed to receive requests from an unauthenticated external actor.
Many MLflow environments are owned by data-science or platform teams rather than conventional application operations. Security leaders need a decision-grade inventory covering self-hosted instances, Internet exposure, authentication, SQL-backed webhook availability and cloud identity, rather than assuming managed AI-platform inventories include every experimental deployment.
The decision for security leaders
Assign discovery beyond the central production estate. Data-science workstations, research clusters, proof-of-concept servers and team-managed cloud instances may expose MLflow without appearing in enterprise application inventories, particularly where experiments use default or lightly governed configurations.
Run patching and compromise assessment in parallel. Upgrade to 3.15.0 or later, but preserve and examine application, reverse-proxy, network-flow and cloud-metadata telemetry for webhook creation, test requests, redirect chains and unusual credential use originating from the MLflow host.
Define credential-containment ownership before evidence emerges. If metadata access cannot be excluded, cloud platform owners must rotate affected role credentials, review downstream API activity and determine whether internal services returned secrets or regulated data through the reflected response.
Evidence of closure
- A reconciled inventory records version, exposure, authentication and owner for every self-hosted MLflow deployment.
- All affected deployments report MLflow version 3.15.0 or later, or have an approved isolation exception.
- Log review finds no unauthorised webhook tests or unexplained requests to internal and metadata addresses.
- Cloud audit evidence shows rotated credentials have no unexplained use after the suspected exposure window.
The Security.io assessment
The KEV addition is the decisive change because it removes the assumption that the public proof of concept represents only prospective risk. Internet-accessible or otherwise untrusted-reachable deployments must be handled as potentially investigated systems, not simply outdated software awaiting a maintenance window.
This flaw crosses control boundaries. The vulnerable MLflow service may be considered a development tool, yet its network position and cloud identity can expose management endpoints, metadata and secrets belonging to other systems. Business impact therefore depends more on reachable resources than on data stored directly in MLflow.
The absence of campaign indicators means defenders cannot close on a blocklist check. Evidence must come from deployment inventory, request logs, network destinations, cloud audit trails and credential activity. Where those records are unavailable, the closure decision should explicitly record uncertainty and favour containment or credential rotation.
Questions for the morning meeting
- Where are self-hosted MLflow tracking servers reachable from untrusted networks?
- Which cloud roles or internal services are accessible from each affected server?
- Can retained logs identify webhook creation, test requests and redirected destinations?
- Who owns credential rotation when metadata access cannot be excluded?