MLflow is an open source AI engineering platform for agents

CVE-2026-64849 is an unauthenticated Server-Side Request Forgery (SSRF) in MLflow's webhook test endpoint (POST /api/2.0/mlflow/webhooks/{id}/test). The _validate_webhook_url() function in mlflow/utils/validation.py resolves the supplied hostname and blocks RFC-1918 / link-local addresses, but mlflow/webhooks/delivery.py follows HTTP 3xx redirects without re-validating the destination. An attacker hosts a public URL that passes the initial check, then issues a redirect to http://169.254.169.254/latest/meta-data/iam/security-credentials/ or any internal service. The full response body is reflected back to the caller. All MLflow versions before 3.15.0 are affected; no authentication or special configuration is required.

The vendor's CRITICAL 9.3 score is accurate and, if anything, generous only in not accounting for the active exploitation. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N) correctly reflects the unauthenticated, network-reachable, cross-scope read. Because MLflow tracking servers are routinely deployed on cloud VMs and containers with attached IAM roles, the practical impact of this full-read SSRF is cloud credential theft at scale — not a theoretical internal port scan. watchTowr's honeypot network confirmed exploitation within hours of disclosure.

Why this verdict

• Zero authentication barrier: The webhook test endpoint requires no credentials, no API key, no session — any network-reachable attacker can fire the exploit with a single POST request. This is the widest possible attack surface.
• Active exploitation confirmed: watchTowr honeypots detected scanning and exploitation within hours of disclosure. This is not theoretical; it is happening now against production MLflow deployments.
• Role multiplier: MLflow tracking servers are CI/CD-adjacent ML infrastructure. They canonically run on cloud VMs/containers with IAM roles granting access to S3/GCS training data, model artifact stores, Secrets Manager, and container registries. ≥50% of MLflow deployments occupy this high-value role by definition. A successful credential theft cascades from host-level to cloud-account-level, enabling data exfiltration and potential supply-chain compromise via model artifact tampering. The blast radius is cloud-account-scale, setting a CRITICAL floor.
• Massive and growing attack surface: Shodan data shows MLflow internet exposure up 173% YoY with thousands of instances publicly reachable, many running default configs with no authentication layer.
• Trivial exploit complexity: The attack requires only a public HTTP redirect server and a single curl command. No memory corruption, no race condition, no chain of bugs — just one request.

Why not higher?

The score is already at 9.3 CRITICAL, which is appropriate. A 10.0 would require arbitrary code execution with no mitigating factors. This is a read-only SSRF (C:H/I:L/A:N), not RCE, and cloud metadata protections (IMDSv2, GKE Workload Identity) do provide a meaningful partial mitigation on hardened deployments.

Why not lower?

Downgrading would require ignoring three compounding factors: (1) active exploitation in the wild, (2) zero authentication requirements on a network-exposed service, and (3) the CI/CD-adjacent role multiplier where credential theft cascades to cloud-account-level compromise. The IMDSv2 friction point only applies to AWS deployments that have enforced it — many have not, and GCP/Azure metadata protections vary. The growing internet exposure surface eliminates any 'niche deployment' argument.

1. Enforce IMDSv2 on all AWS instances running MLflow — IMDSv2 requires a PUT request with a hop-limit-1 token before credential retrieval. MLflow's redirect-based SSRF cannot satisfy this, completely blocking the credential-theft path on AWS. Deploy within 3 days per noisgate mitigation SLA for CRITICAL findings. Use aws ec2 modify-instance-metadata-options --instance-id <id> --http-tokens required --http-put-response-hop-limit 1.
2. Place MLflow behind an authenticating reverse proxy or VPN — MLflow has no built-in authentication. Deploy an OAuth2 proxy, Cloudflare Access, or restrict access to VPN/Zero-Trust overlay within 3 days. This eliminates the unauthenticated attack vector entirely.
3. Deploy network-level metadata firewall — On GKE, enable Workload Identity. On EKS, use IRSA instead of instance profiles. On bare VMs, use iptables to block the MLflow process from reaching 169.254.169.254. Deploy within 3 days.
4. Apply WAF rules blocking SSRF payloads — Configure WAF to inspect POST body parameters for 169.254.169.254, 127.0.0.1, and RFC-1918 ranges in webhook URL fields. This provides defense-in-depth but is bypassable via DNS rebinding.
5. Upgrade to MLflow 3.15.0 — The definitive fix. The patched version re-validates redirect destinations against the same IP blocklist. Plan upgrade within the 90-day noisgate remediation SLA, but given active exploitation, prioritize immediate deployment.

Run this script on each host running MLflow (or from an auditor workstation with pip access to the MLflow environment). No special privileges required. Invoke: bash check_cve_2026_64849.sh or bash check_cve_2026_64849.sh /path/to/python

#!/usr/bin/env bash
# CVE-2026-64849 checker — MLflow unauthenticated SSRF in webhook delivery
# Usage: bash check_cve_2026_64849.sh [/path/to/python]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PYTHON="${1:-python3}"

if ! command -v "$PYTHON" &>/dev/null; then
  echo "UNKNOWN — python3 not found"
  exit 2
fi

VERSION=$($PYTHON -c "import mlflow; print(mlflow.__version__)" 2>/dev/null) || {
  echo "UNKNOWN — mlflow is not installed in this Python environment"
  exit 2
}

echo "Detected MLflow version: $VERSION"

# Compare versions using Python for reliability
RESULT=$($PYTHON -c "
from packaging.version import Version
import sys
try:
    v = Version('$VERSION')
    if v >= Version('3.15.0'):
        print('PATCHED')
    else:
        print('VULNERABLE')
except Exception as e:
    print('UNKNOWN')
" 2>/dev/null) || {
  # Fallback if packaging module unavailable
  RESULT=$($PYTHON -c "
import sys
parts = '$VERSION'.split('.')
try:
    major, minor = int(parts[0]), int(parts[1])
    if (major > 3) or (major == 3 and minor >= 15):
        print('PATCHED')
    else:
        print('VULNERABLE')
except:
    print('UNKNOWN')
")
}

echo "$RESULT — CVE-2026-64849 (MLflow SSRF in webhook delivery)"
case "$RESULT" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. CyberPress — Hackers Exploit MLflow SSRF Flaw
2. GitLab Advisory Database — CVE-2026-64849
3. THREATINT — CVE-2026-64849
4. GHSA-7gwp-5pfp-969j — GitHub Security Advisory
5. OpenA2A Research — AI Exposure Sweep April 2026
6. CWE-918: Server-Side Request Forgery
7. MLflow GitHub — Fix PR #24258