Date: August 18, 2026
Author: DigitalSpying Threat Research Team
Category: AI Security / Cloud Security / Threat Intelligence
Executive Summary
A critical Server-Side Request Forgery (SSRF) vulnerability affecting MLflow—the industry-standard open-source machine learning lifecycle and experiment tracking platform—is being actively exploited in the wild. Tracked as CVE-2026-64849 with a critical CVSS v3 score of 9.3, the flaw enables unauthenticated remote attackers who can reach an exposed MLflow Tracking Server (mlflow server) to forge HTTP requests originating from the server host. Threat intelligence telemetry from watchTowr and VulnCheck confirms active in-the-wild exploitation targeting cloud-hosted MLflow instances to harvest instance metadata, temporary AWS IAM role credentials, GCP service account tokens, and internal cluster secrets.
Deep-Dive Technical Analysis
Architecture & Root Cause
MLflow is widely deployed across enterprise data science and AI teams to track experiment metrics, manage model artifacts, and register production AI pipelines. The vulnerability lies within the MLflow Tracking Server's artifact downloading and remote URL fetching endpoints.
While previous security updates attempted to restrict server-initiated network requests to local and trusted domains, CVE-2026-64849 bypasses these validation filters through improper handling of HTTP 30x redirects and protocol wrapping. When an attacker supplies a benign-looking external URL that responds with an HTTP 302 redirect pointing to an internal loopback or cloud metadata address, the internal HTTP client follows the redirect without re-evaluating the destination IP against the SSRF blacklist.
Exploit Mechanics: Targeting Cloud Metadata Services
Attackers are weaponizing this redirect bypass to query cloud provider Instance Metadata Services (IMDS):
1. AWS EC2 IMDSv1 (http://169.254.169.254/latest/meta-data/iam/security-credentials/): On AWS instances where IMDSv2 is not strictly enforced, the tracking server retrieves the temporary security keys (AccessKeyId, SecretAccessKey, Token) assigned to the EC2 instance role and echoes them in the server response or error log.
2. Google Cloud Metadata (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token): By appending required HTTP headers via crafted redirection headers, attackers attempt token exfiltration.
3. Internal Kubernetes & Microservice Probing: The SSRF allows attackers to scan internal cluster subnets (10.0.0.0/8, 172.16.0.0/12), discovering unprotected Redis instances, internal Kubernetes API servers (kubernetes.default.svc), and private S3-compatible artifact stores.
Telemetry from watchTowr's Attacker Eye global honeypot network observed widespread scanning within hours of public disclosure, originating from automated exploit scripts attempting to extract environment secrets and cloud access tokens.
Parallel Threat Note: FUXA Industrial Automation Scanning
Simultaneously, VulnCheck reported active automated scanning targeting FUXA (CVE-2026-25895), an open-source web-based SCADA / HMI software used in industrial operational technology (OT). Attackers are actively scanning approximately 60 public-facing FUXA instances attempting path-traversal overwrites on core JavaScript files (main.js).
Industry Impact & Risk Assessment
The weaponization of CVE-2026-64849 represents a severe threat to enterprise AI/ML operations:
* Cloud Account Takeover: Stolen instance role credentials frequently possess extensive permissions (e.g., read/write access to S3 training data buckets, Amazon SageMaker, or Elastic Container Registry).
* Proprietary Model & Intellectual Property Theft: Attackers can access sensitive proprietary weights, training datasets, and proprietary customer algorithms.
* Model Poisoning & Supply Chain Tampering: Attackers with write access to artifact repositories can alter model artifacts, injecting backdoors into inference pipelines.
Mitigation Strategies & Remediation Guidance
Organizations deploying MLflow must take immediate defensive action:
1. Apply Security Patches: Upgrade all MLflow installations immediately to the latest patched release (MLflow 2.15.2+).
2. Restrict Network Exposure: Never expose mlflow server directly to the public internet. Enforce strict VPN, private subnet isolation, or zero-trust reverse proxy authentication (e.g., OAuth2-Proxy).
3. Enforce AWS IMDSv2 with Hop Limits: Require IMDSv2 (HttpTokens=required) across all cloud instances and configure the metadata response hop limit to 1 (HttpPutResponseHopLimit=1) to prevent containerized SSRF egress.
4. Implement Egress Filtering: Configure host and container firewall rules (e.g., iptables / AWS Security Groups) to block egress traffic from MLflow worker containers to 169.254.169.254 and internal management subnets.
5. Credential Rotation & Forensic Auditing: Rotate any IAM credentials, API keys, or database passwords accessible to exposed MLflow hosts. Audit cloud provider access logs (AWS CloudTrail, GCP Cloud Audit Logs) for unauthorized API calls originating from anomalous external IP addresses.