A webhook points to an ordinary public HTTPS address. The server approves it. One redirect later, that same request is reading a cloud metadata endpoint that was never meant to face the internet.
That is the short version of MLflow SSRF vulnerability CVE-2026-64849. On August 19, 2026, the US Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalog. CISA’s record says exploitation is active and gives US federal agencies a September 2 remediation deadline.
The record does not name an attacker, a campaign, or a victim count. It does settle the question that matters for operators: this is no longer a theoretical bug waiting for someone to try it. If an MLflow Tracking Server is reachable, checking the version and exposure belongs on today’s list.
The server checked one address and connected to another
MLflow’s webhook protection resolved the hostname supplied by a user and rejected addresses that were not public. That sounds sensible. The missing step came after the check.
According to the GitHub security advisory, webhook delivery followed HTTP redirects and opened a fresh connection without pinning or revalidating the approved address. A public HTTPS endpoint could therefore pass validation, respond with a redirect, and send MLflow toward a loopback address, a private service, or a cloud metadata address.
The webhook test route made the flaw more useful to an attacker. The endpoint returned the upstream status and response body. A successful request could turn MLflow into a reader for resources that were visible to the server but not to the attacker.
A 302 could read; a 307 or 308 could write
The advisory separates two redirect behaviors. A 302 typically converts the follow-up into a GET request, which can retrieve an internal response. A 307 or 308 preserves the original POST method and body, creating a blind-write path toward an internal endpoint that accepts POST requests.
That difference matters during incident review. Looking only for stolen metadata can miss attempted writes to administrative services. Looking only for a successful response can miss a blind action that returned little useful output.
The advisory also describes DNS rebinding as another route around the original check. The hostname could resolve to a public address during validation and a different address when the HTTP client connected. Both paths share the same design mistake: validating a name once did not constrain the destination of the actual socket.
Who should treat this as exposed
| Question | Higher-risk answer | Immediate check |
|---|---|---|
| Can an untrusted network reach the Tracking Server? | Yes, directly or through a permissive proxy | Confirm firewall, load-balancer, and authentication boundaries |
| Are model-registry webhooks available? | Yes, on a SQL-backed server | Inventory webhook creation and test requests |
| Can the server reach private networks or metadata services? | Yes | Test egress policy from the server’s own network identity |
| Is the running release older than 3.15.0? | Yes or unknown | Map the deployed build to its package and container digest |
| Could metadata contain usable credentials? | Yes | Review metadata protections and prepare scoped rotation |
The vulnerable surface is not every notebook that imports MLflow. The advisory concerns the Tracking Server’s model-registry webhook API. A default server without the optional authentication plugin is especially important because the relevant routes can be unauthenticated. The webhook feature also needs a SQL store.
Do not turn those conditions into reassurance too quickly. An internal MLflow service can still be reachable through a forgotten ingress, a shared development network, a misconfigured tunnel, or a compromised workload. Our review of the AISI cyber-test incidents reached the same operational lesson: written scope loses when the network allows the action.
Version 3.15.0 is the practical patch boundary
The NVD record says versions before 3.15.0 are affected and identifies 3.15.0 as the fixed release. The patch adds connection-time protection that checks the peer address after the socket connects, before HTTP or TLS data is exchanged. Redirects open new connections through the same protected adapter, so their destinations are checked too.
There is a documentation wrinkle worth recording. The GitHub advisory’s structured “patched versions” field still says “no,” while its fix section points to pull request 24258 and the same commit that NVD maps to the 3.15.0 release. Operators should verify the actual deployed artifact rather than relying on a dashboard field copied into a scanner.
If a vendor image or managed service uses its own build number, ask for the commit mapping. “Latest” is not evidence. A package version, container digest, or software bill of materials that proves the fix is present is.
The response needs more than an upgrade
- Find every Tracking Server. Include development machines, old containers, demo environments, and services exposed only through VPNs or tunnels.
- Record the build. Capture the MLflow version, image digest, deployment time, authentication mode, SQL backend, and webhook configuration.
- Upgrade to a build containing the 3.15.0 fix. Rebuild immutable images rather than patching a running container and forgetting its source.
- Constrain egress. Block cloud metadata, loopback, private ranges, administrative networks, and destinations the service does not need. Test redirects and DNS changes, not only direct URLs.
- Review evidence. Search access logs for webhook creation and test calls, unexpected redirect hosts, metadata paths, and connections from the MLflow network identity to internal services.
- Rotate selectively. If the server could reach credentials and suspicious activity exists, revoke the exposed identity and investigate what it could access before issuing a replacement.
This is also a useful test for agent infrastructure. A model, evaluation service, or automation runner should not inherit broad cloud credentials just because it needs to log experiments. The permissions guidance in our Burp AT agent review applies here: authority belongs in infrastructure controls, not in a promise that the application will only ask for safe destinations.
My verdict: treat the redirect as a new request
The bug is technically specific, but the design lesson travels. Checking the URL a user submitted is not enough when the HTTP client can follow a redirect or resolve the name again. Every new connection needs to satisfy the same destination policy.
Patch MLflow first because CISA says exploitation is happening. Then keep the egress boundary. The next SSRF will not care that the application passed its own validation function.
Read the source record
- Check CISA’s KEV entry for CVE-2026-64849.
- Read the MLflow GitHub security advisory.
- Review the fix pull request and 3.15.0 release.
- Compare the NVD version and exploitation record.
Can your MLflow server reach anything that an unauthenticated internet user cannot?
Checked August 24, 2026. Active exploitation and the federal due date come from CISA. Technical behavior and severity come from the MLflow GitHub advisory. The version boundary comes from NVD and the linked 3.15.0 release record.
