Threat actors are actively targeting a critical vulnerability in MLflow, an open-source platform widely used for machine-learning experiment tracking, model management and deployment.
The vulnerability, tracked as CVE-2026-64849, is an unauthenticated Server-Side Request Forgery (SSRF) flaw with a CVSS score of 9.3.
According to watchTowr, attackers began scanning internet-exposed MLflow instances within hours of the CVE being assigned on August 17, 2026. The observed activity targeted cloud-hosted MLflow deployments to access internal services and cloud metadata endpoints containing credentials and secrets.
Key Highlights
- Vulnerability: CVE-2026-64849
- CVSS: 9.3 Critical
- Product: MLflow
- Vulnerability: Unauthenticated SSRF
- Affected versions: Before 3.15.0
- Authentication required: None
- Exploitation observed in the wild
- MLflow Tracking Server is the primary attack surface
- Attackers can reach internal cloud metadata services
- AWS IAM credentials and other cloud secrets may be exposed
- Exploitation can abuse model-registry webhook functionality
- MLflow 3.15.0 contains the remediation.
Vulnerability Overview
CVE-2026-64849 exists in MLflow's model-registry webhook functionality.
An exposed MLflow Tracking Server can allow unauthenticated requests to the webhook testing endpoint:
/api/2.0/mlflow/webhooks/{id}/test
The endpoint can cause the MLflow server to make HTTP requests on behalf of an attacker and return information from the upstream response.
This effectively turns the MLflow server into an SSRF proxy.
SSRF Exploitation
SSRF vulnerabilities are particularly dangerous in cloud environments because the vulnerable server may have access to internal services that are not directly reachable from the internet.
An attacker can potentially use the MLflow server to interact with:
- Internal HTTP services
- Localhost services
- Cloud metadata endpoints
- Internal administrative interfaces
- Container or orchestration services
- Cloud credential endpoints
The attacker therefore uses the compromised MLflow server as a trusted network position.
Cloud Metadata Theft
The most significant risk involves cloud metadata services.
Cloud metadata endpoints can expose temporary credentials associated with workloads running on:
- Amazon EC2
- Kubernetes nodes
- Cloud-hosted ML infrastructure
- Other cloud compute environments
If these credentials have excessive permissions, compromise of an MLflow server can potentially lead to broader cloud-environment compromise.
Validation Bypass
MLflow previously introduced URL validation to prevent webhooks from reaching private or reserved IP addresses.
However, the validation did not adequately protect against changes to the final destination after the initial validation.
The vulnerability can therefore be abused through techniques involving:
- HTTP redirects
- DNS rebinding
- Destination changes after validation
The initial destination may appear legitimate while the final request is redirected toward an internal resource.
Active Exploitation
watchTowr's global honeypot infrastructure observed attackers indiscriminately scanning for exposed MLflow systems shortly after the vulnerability was disclosed.
The observed exploitation attempts specifically attempted to reach internal services and cloud metadata endpoints to retrieve credentials and secrets.
The speed of exploitation demonstrates that newly disclosed vulnerabilities affecting internet-facing AI infrastructure can be weaponized extremely quickly.
Potential Impact
Successful exploitation could result in:
- Cloud credential theft
- Exposure of IAM credentials
- Access to internal services
- Theft of deployment secrets
- Access to cloud storage
- Unauthorized model or experiment data access
- Further cloud privilege escalation
- Lateral movement
- Persistence within cloud environments
The final impact depends heavily on the permissions assigned to the MLflow workload's cloud identity.
Detection and Hunting Opportunities
Security teams should monitor for:
- Internet-accessible MLflow Tracking Servers
-
Requests to
/api/2.0/mlflow/webhooks/ -
Requests to
/webhooks/{id}/test - Unusual webhook testing activity
- MLflow servers making requests to private IP addresses
- Requests to cloud metadata IPs
-
Connections to
169.254.169.254 -
Unexpected connections to
127.0.0.1 - MLflow outbound requests to internal services
- Suspicious HTTP redirects
- DNS rebinding behavior
- Unexpected cloud credential usage
- IAM activity originating from unusual locations
- New cloud API sessions following MLflow exploitation attempts
Recommended Mitigations
- Upgrade MLflow to 3.15.0 or later immediately.
- Identify all internet-exposed MLflow Tracking Servers.
- Remove unnecessary public exposure.
- Restrict MLflow access to trusted networks.
- Review MLflow webhook configurations.
- Monitor requests to webhook testing endpoints.
- Block MLflow workloads from accessing unnecessary cloud metadata services.
- Use cloud-native metadata protections where available.
- Apply least privilege to MLflow IAM roles and service accounts.
- Rotate cloud credentials if exploitation is suspected.
- Review cloud audit logs for unusual API activity.
- Investigate unexpected outbound requests from MLflow servers.
- Search historical logs for SSRF attempts beginning August 17, 2026.
- Revoke exposed temporary credentials and tokens.
Threat Assessment
CVE-2026-64849 represents a critical cloud-security risk because an attacker does not need valid credentials to exploit an exposed MLflow Tracking Server.
The ability to pivot from an internet-facing MLflow service toward internal cloud metadata endpoints significantly increases the potential impact.
The rapid exploitation observed after disclosure also makes immediate patching particularly important.
Conclusion
Organizations running MLflow should immediately identify internet-exposed deployments and upgrade affected systems to version 3.15.0 or later.
Security teams should also perform retrospective hunting for requests against MLflow webhook endpoints and investigate any attempts to access cloud metadata services.
If an exposed MLflow instance may have been exploited, organizations should assume that associated cloud credentials could have been exposed and rotate them accordingly.