The AI Platform Was the Door. The Cloud Identity Was the Prize.
Attackers are exploiting an MLflow flaw that can turn an exposed AI engineering service into a proxy for reading cloud metadata and internal systems. The application may not hold the most valuable secret. Its network position and cloud identity are the prize.
An AI platform can become a bridge into cloud identity
CVE-2026-64849 is a critical server-side request forgery vulnerability in MLflow’s webhook delivery. The default Tracking Server exposes model-registry webhook functions without authentication, including a test endpoint that returns the upstream status and response body to the caller.
That response makes the flaw more useful than blind network probing. An attacker can make the MLflow server contact a destination that is reachable from the server but not from the internet, then read the result through the webhook test response.
Cloud instance-metadata services are a particularly important target. Depending on the environment and its controls, metadata can expose temporary credentials associated with the compute instance. The vulnerable AI platform becomes the route, while the surrounding cloud identity becomes the asset the attacker wants.
The original URL check did not control the final connection
MLflow already tried to block unsafe webhook destinations. It required an HTTPS first hop and rejected hostnames that resolved to private, loopback or link-local addresses.
The problem was that the validation result was not pinned to the connection. A public HTTPS endpoint could pass the check and respond with a redirect to an internal address such as the cloud metadata service. MLflow followed the redirect without validating the new destination. DNS rebinding created a second route because the hostname could resolve differently between validation and connection.
The fix validates the peer IP of the actual connected socket before TLS or HTTP data is exchanged. That matters because the control is applied to the connection that will carry the request, including connections created for redirects.
CISA says exploitation is already occurring
CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on 19 August 2026 and set 2 September as the remediation due date for US federal civilian agencies. That listing separates the issue from a theoretical proof of concept: exploitation has been confirmed in the wild.
MLflow 3.15.0 includes the relevant connection-time protection. Exposed operators should upgrade to 3.15.0 or later, verify the version actually running in containers and managed images, and restart or redeploy the service so the fixed code is active.
Treat an exposed Tracking Server as an investigation target
Defenders should:
- Remove public access to MLflow Tracking Servers unless it is explicitly required and protected.
- Require authentication and place the service behind an access-controlled gateway.
- Block workload access to cloud metadata where it is not required and use the provider’s hardened metadata controls.
- Review webhook creation, update and test activity for attacker-controlled public hosts, redirects and unusual destinations.
- Inspect outbound requests from the MLflow service to metadata, loopback and private-network addresses.
- Rotate cloud credentials if evidence suggests metadata responses were retrieved.
- Review internal services reachable from the MLflow host and determine what the workload identity could access.
The environment variable that permits private webhook destinations exists for local development. It should not be enabled casually in production, because it deliberately relaxes the boundary the protection is meant to enforce.
AI engineering services are control-plane assets
ML platforms often sit close to model registries, data stores, object storage, CI systems and cloud credentials. Teams may expose them as development conveniences without applying the scrutiny normally reserved for administrative infrastructure.
This incident shows why that distinction is unsafe. An AI platform can become a control-plane asset even when it was deployed as a developer tool. Its permissions, network reachability and instance identity deserve the same review as any other system that can move across trust boundaries.
