CISA’s alert identifies the issue as an MLflow SSRF vulnerability but does not name affected releases, a remediation deadline, or a required fixed version. The upstream MLflow security advisory fills in much of that gap: it describes an unauthenticated full-read SSRF affecting the default tracking-server configuration and assigns a CVSS score of 9.3. Yet the official upstream records also contain a versioning contradiction that administrators should resolve by inventory and testing rather than assuming a scanner’s status field tells the whole story.
The vulnerable path is MLflow’s webhook test API
According to MLflow’s GitHub security advisory, the vulnerability sits in model-registry webhook handling. A default MLflow Tracking Server exposes webhook management and testing endpoints without authentication unless an optional authentication component has been deliberately configured.
The vulnerable logic attempts to block webhooks that point directly at private, loopback, link-local, or cloud-metadata IP addresses. It checks the hostname supplied when the webhook is created, but the outbound HTTP client can subsequently follow a redirect or resolve the hostname again during connection. That creates a gap between validation and use.
An attacker can supply a public HTTPS webhook address that passes the initial validation, then make that server redirect MLflow to an internal destination. The upstream advisory says MLflow’s webhook test endpoint returns the remote response body to the caller. In the worst configuration, this turns what would otherwise be a blind request forgery bug into a way to retrieve responses from internal HTTP services.
For Windows-based development and data-science teams, the affected system is typically not a Windows component. It is the Python-based MLflow service that may be running in a Linux container, on a Windows Server host, in Kubernetes, or on a cloud virtual machine managed from Windows endpoints. The operating system is secondary; internet exposure and default server configuration are the decisive factors.
The advisory’s examples include cloud instance metadata, loopback services, internal administrative interfaces, and network probing. In an Azure-hosted deployment, the practical concern is that a server-side request can cross the boundary that an external caller should not be able to cross, reaching infrastructure services visible only from the workload’s network position.
Why CISA’s KEV listing changes the priority
A CVE score describes a vulnerability’s theoretical severity. CISA’s Known Exploited Vulnerabilities catalog is meant to signal something more operationally urgent: evidence that exploitation is happening outside a lab or proof of concept.
CISA’s August 19 notice says it added CVE-2026-64849 based on active exploitation. The agency did not publish technical indicators, victim details, attribution, or a description of the observed campaigns in that alert. Administrators should not invent those missing facts, but they also should not read the absence of public campaign detail as a reason to defer action. The catalog addition itself is CISA’s actionable finding.
The agency’s current Binding Operational Directive 26-04 applies directly to Federal Civilian Executive Branch agencies and prioritizes remediation based on risk, especially for publicly exposed assets where compromise can produce total control. MLflow’s advisory describes a route to internal-service access and metadata retrieval, not a universally demonstrated host takeover. That distinction is important: CISA’s KEV entry establishes exploitation, but it does not establish that every exposed MLflow server has been fully compromised.
Even so, the path to material damage can be short when MLflow has access to cloud credentials, internal APIs, model artifacts, or an over-privileged service identity. A tracking server is often treated as a development tool, then retained as a shared production dependency. That makes it a tempting boundary-crossing target: a public-facing application with access to systems and data that are deliberately not public.
The upstream records disagree on the patch status
MLflow’s GitHub security advisory lists versions through 3.13.0 as affected and, unusually, shows “no” under patched versions. But the same advisory says the flaw was fixed in pull request 24258, which added connection-time checks on the actual peer IP rather than relying solely on hostname validation.
The pull request was merged into MLflow’s main branch on July 2, 2026. Its release-note metadata marks the change as a critical security fix intended for the next patch release and carries a 3.14.1 label. The project later published MLflow 3.15.0 on July 31. On chronology alone, version 3.15.0 should contain a fix merged into the main branch nearly a month earlier, but MLflow’s release notes do not explicitly identify this CVE, and the security advisory was not updated to name a patched release.
That is more than documentation sloppiness. A vulnerability-management team needs a verifiable answer to two questions: which deployed versions remain vulnerable, and which package build demonstrably contains the correction. The official record currently gives conflicting signals:
- The GitHub advisory says MLflow 3.13.0 and earlier are affected, while leaving the patched-version field blank.
- The fix pull request says it closes CVE-2026-64849 and was targeted for a 3.14.1 patch release.
- MLflow 3.15.0 was released after the fix merged, but its published notes do not explicitly connect the release to CVE-2026-64849.
The safe operational conclusion is not to wait for a metadata cleanup. Organizations running MLflow 3.13.0 or earlier should treat themselves as affected. Organizations that believe they are protected because they run 3.14.x or 3.15.0 should verify that their installed package includes the connection-time SSRF protection described in pull request 24258, rather than relying only on a version string or advisory field.
Default deployments deserve the first look
The MLflow advisory focuses on a default server using the default SQLite-backed setup and no authentication. That is significant because those conditions are common in proof-of-concept, lab, and small-team deployments. The model-registry webhook feature requires a SQL store, and the default SQLite configuration meets that prerequisite.
An attacker must be able to reach the MLflow tracking server. Systems bound only to loopback, protected behind a properly configured VPN, or isolated behind an authenticated reverse proxy have a smaller reachable attack surface. But network placement is a mitigation, not a repair. Once an attacker can access the relevant API endpoints from a permitted network location, the vulnerable server can still be induced to reach services on its own network.
Authentication also changes exposure, but it should not be used as the sole closure criterion. The upstream advisory describes the default webhook endpoints as unauthenticated; organizations that enable MLflow’s optional authentication or place an identity-aware proxy in front of the service should verify, with an unauthenticated request from outside the trust boundary, that webhook creation and webhook testing are actually denied.
The vulnerability’s redirect behavior also means ordinary URL allowlists can be misleading. Blocking obvious private addresses at webhook-creation time does not help if a publicly valid destination can redirect the server after it has passed validation. The upstream fix addresses this by validating the IP address of the socket actually connected to, before the application exchanges HTTP or TLS data.
What administrators should do today
Start by locating every self-hosted MLflow Tracking Server, including development systems. Look for Python package installations, containers, Helm deployments, Kubernetes services, cloud instances, and reverse-proxy back ends rather than assuming the platform team owns every instance. MLflow is frequently introduced by engineering or data teams outside normal server-provisioning workflows.
For each instance, establish whether all of the following are true:
- The server is reachable from the public internet or from a broad internal network segment.
- The deployment exposes the MLflow model registry and webhook APIs.
- Authentication is absent, optional but disabled, or enforced only by assumptions about network reachability.
- The installed MLflow build predates the confirmed connection-time SSRF fix or cannot be shown to include it.
- The workload identity can reach sensitive internal services, cloud metadata, secrets systems, or privileged management APIs.
Where the version cannot immediately be confirmed as fixed, remove public access, restrict inbound access to explicitly trusted identities and networks, and block the server’s ability to reach link-local metadata addresses and unnecessary internal destinations. Egress filtering will not replace the software fix, but it can limit what a successful SSRF request reaches while the service is upgraded and validated.
Teams should also review webhook records and HTTP egress logs for unexpected webhook destinations, redirect chains, connections to loopback or link-local ranges, and requests to cloud metadata paths. CISA says exploitation has been observed; checking only whether the package is patched leaves open the question of whether a vulnerable server was already used before remediation.
The concrete next step is to treat this as an exposed-service incident, not a routine Python dependency update. Patch or isolate affected MLflow servers, verify the actual build contains the upstream connection-time protection, rotate credentials reachable from the service where suspicious activity is found, and document the exposure before CISA’s KEV listing becomes the explanation for why the system was discovered too late.
