CVE-2026-64849: MLflow unauth SSRF

Q: Is CVE-2026-64849 actively exploited?

Yes, CVE-2026-64849 is confirmed actively exploited and listed in CISA Known Exploited Vulnerabilities catalog since Wed Aug 19 2026 00:00:00 GMT+0000 (Coordinated Universal Time).

Q: How to fix CVE-2026-64849?

1) Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix, since it pins the validated address through redirect handling. 2) Until patched, restrict or disable the `/api/2.0/mlflow/webhooks/{id}/test` endpoint (and ideally all webhook management) behind authentication/network ACLs at the reverse proxy or API gateway. 3) Apply network-level egress controls on the MLflow host: block outbound requests to RFC1918/link-local ranges and enforce IMDSv2 with a hop limit of 1 on cloud instances to blunt metadata-service SSRF even if the app-layer bug is present. 4) Detection: review MLflow server logs / webhook delivery history for outbound test requests to unexpected internal IPs or metadata addresses (169.254.169.254, 100.100.100.200, etc.), and alert on any webhook URL configured with a redirect-capable shortener or attacker-controlled domain. 5) Rotate any cloud IAM credentials that may have been exposed if the endpoint was reachable pre-patch and logs show anomalous webhook test traffic.

Q: What systems are affected by CVE-2026-64849?

This vulnerability affects the following AI/ML architecture patterns: MLOps / experiment tracking platforms, model registry infrastructure, cloud-hosted ML training and deployment pipelines, CI/CD integrations for model publishing.

Q: What is the CVSS score for CVE-2026-64849?

CVE-2026-64849 has a CVSS v3.1 base score of 9.3 (CRITICAL). The EPSS exploitation probability is 9.84%.

CISO Take

MLflow's webhook test endpoint validates the target URL once but then follows HTTP redirects without re-checking where they actually resolve, so an unauthenticated caller can point it at a redirector that lands on an internal service or a cloud metadata endpoint (e.g. 169.254.169.254) and get the full response back in the API reply. This is a critical, network-exploitable, zero-privilege bug (CVSS 9.3) in a platform with 683 downstream dependents and a mediocre OpenSSF Scorecard (5.6/10) plus 78 other known CVEs in the package, so any internet-reachable or multi-tenant MLflow deployment is a realistic target even without a public PoC or KEV listing yet. The technique is a textbook SSRF-via-redirect bypass, meaning it's trivial to reproduce once triaged, and the payoff — cloud IAM credentials or internal admin interfaces — is high value in typical ML infrastructure. Patch to MLflow 3.15.0 immediately; if you can't patch today, block or authenticate the `/api/2.0/mlflow/webhooks/*` routes at the reverse proxy, disable outbound redirects at the network layer for the MLflow host, and enforce IMDSv2 / metadata-service network policies (hop limit 1, block from app subnets) as compensating controls. Audit webhook configs and outbound request logs from the MLflow server for calls to link-local (169.254.0.0/16) or RFC1918 ranges as a detection signal.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Critical exploitability profile: unauthenticated (PR:N), no user interaction, low attack complexity, network vector, and a well-understood bypass class (SSRF via unvalidated redirect). No public exploit or Nuclei template exists yet and it is not in CISA KEV, so there is no evidence of active exploitation, but the simplicity of the bypass (send a URL to a server the attacker controls, have it 302 to the real target) makes weaponization straightforward for anyone who reads the advisory. The Scope:Changed rating and Confidentiality:High reflect that the impact extends beyond the MLflow process itself — into whatever internal network or cloud IAM plane the server can reach. Combined with mlflow's poor security track record (78 prior CVEs, Scorecard 5.6/10) and broad adoption (683 dependents), this should be treated as urgent-patch-now, not wait-and-see.

How does the attack unfold?

Recon & Access

Attacker locates an internet-reachable MLflow server and calls the unauthenticated webhook test endpoint.

AML.T0049

SSRF via Redirect Bypass

Attacker submits a webhook URL that passes initial validation but redirects to an internal or cloud metadata address, which MLflow follows without re-validating.

Credential/Data Harvest

MLflow returns the fetched response_status and response_body to the attacker, exposing cloud IAM credentials or internal service data.

AML.T0075

Lateral Movement / Impact

Attacker uses harvested credentials to access cloud storage, internal APIs, or other infrastructure beyond the MLflow server itself.

Recon & Access

Attacker locates an internet-reachable MLflow server and calls the unauthenticated webhook test endpoint.

AML.T0049

SSRF via Redirect Bypass

Attacker submits a webhook URL that passes initial validation but redirects to an internal or cloud metadata address, which MLflow follows without re-validating.

Credential/Data Harvest

MLflow returns the fetched response_status and response_body to the attacker, exposing cloud IAM credentials or internal service data.

AML.T0075

Lateral Movement / Impact

Attacker uses harvested credentials to access cloud storage, internal APIs, or other infrastructure beyond the MLflow server itself.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	< 3.15.0	`3.15.0`
28.1K OpenSSF 5.3 691 dependents Pushed 5d ago 36% patched ~75d to patch Full package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1

9.3 / 10

EPSS

9.8%

chance of exploitation in 30 days

Higher than 95% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Actively Exploited

CISA KEV

Sophistication

Trivial

Exploitation Confidence

high

✓ CISA KEV (active exploitation confirmed) — Aug 2026

✓ CISA SSVC: Active exploitation

○ Public PoC indexed (trickest/cve)

○ Nuclei detection template available

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Changed

C High

I Low

A None

What should I do?

1 step

1) Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix, since it pins the validated address through redirect handling. 2) Until patched, restrict or disable the /api/2.0/mlflow/webhooks/{id}/test endpoint (and ideally all webhook management) behind authentication/network ACLs at the reverse proxy or API gateway. 3) Apply network-level egress controls on the MLflow host: block outbound requests to RFC1918/link-local ranges and enforce IMDSv2 with a hop limit of 1 on cloud instances to blunt metadata-service SSRF even if the app-layer bug is present. 4) Detection: review MLflow server logs / webhook delivery history for outbound test requests to unexpected internal IPs or metadata addresses (169.254.169.254, 100.100.100.200, etc.), and alert on any webhook URL configured with a redirect-capable shortener or attacker-controlled domain. 5) Rotate any cloud IAM credentials that may have been exposed if the endpoint was reachable pre-patch and logs show anomalous webhook test traffic.

What does CISA's SSVC say?

Decision Act

Exploitation active

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Auth Bypass Data Leakage Framework API AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.8.3 - Information security for AI systems

NIST AI RMF

MANAGE-4.1 - Post-deployment risk monitoring and response

Frequently Asked Questions

What is CVE-2026-64849?

MLflow's webhook test endpoint validates the target URL once but then follows HTTP redirects without re-checking where they actually resolve, so an unauthenticated caller can point it at a redirector that lands on an internal service or a cloud metadata endpoint (e.g. 169.254.169.254) and get the full response back in the API reply. This is a critical, network-exploitable, zero-privilege bug (CVSS 9.3) in a platform with 683 downstream dependents and a mediocre OpenSSF Scorecard (5.6/10) plus 78 other known CVEs in the package, so any internet-reachable or multi-tenant MLflow deployment is a realistic target even without a public PoC or KEV listing yet. The technique is a textbook SSRF-via-redirect bypass, meaning it's trivial to reproduce once triaged, and the payoff — cloud IAM credentials or internal admin interfaces — is high value in typical ML infrastructure. Patch to MLflow 3.15.0 immediately; if you can't patch today, block or authenticate the `/api/2.0/mlflow/webhooks/*` routes at the reverse proxy, disable outbound redirects at the network layer for the MLflow host, and enforce IMDSv2 / metadata-service network policies (hop limit 1, block from app subnets) as compensating controls. Audit webhook configs and outbound request logs from the MLflow server for calls to link-local (169.254.0.0/16) or RFC1918 ranges as a detection signal.

Is CVE-2026-64849 actively exploited?

Yes, CVE-2026-64849 is confirmed actively exploited and listed in CISA Known Exploited Vulnerabilities catalog since Wed Aug 19 2026 00:00:00 GMT+0000 (Coordinated Universal Time).

How to fix CVE-2026-64849?

1) Upgrade to MLflow 3.15.0 or later immediately — this is the only complete fix, since it pins the validated address through redirect handling. 2) Until patched, restrict or disable the `/api/2.0/mlflow/webhooks/{id}/test` endpoint (and ideally all webhook management) behind authentication/network ACLs at the reverse proxy or API gateway. 3) Apply network-level egress controls on the MLflow host: block outbound requests to RFC1918/link-local ranges and enforce IMDSv2 with a hop limit of 1 on cloud instances to blunt metadata-service SSRF even if the app-layer bug is present. 4) Detection: review MLflow server logs / webhook delivery history for outbound test requests to unexpected internal IPs or metadata addresses (169.254.169.254, 100.100.100.200, etc.), and alert on any webhook URL configured with a redirect-capable shortener or attacker-controlled domain. 5) Rotate any cloud IAM credentials that may have been exposed if the endpoint was reachable pre-patch and logs show anomalous webhook test traffic.

What systems are affected by CVE-2026-64849?

This vulnerability affects the following AI/ML architecture patterns: MLOps / experiment tracking platforms, model registry infrastructure, cloud-hosted ML training and deployment pipelines, CI/CD integrations for model publishing.

What is the CVSS score for CVE-2026-64849?

CVE-2026-64849 has a CVSS v3.1 base score of 9.3 (CRITICAL). The EPSS exploitation probability is 9.84%.

What is the AI security impact?

Affected AI Architectures

MLOps / experiment tracking platformsmodel registry infrastructurecloud-hosted ML training and deployment pipelinesCI/CD integrations for model publishing

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.8.3

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. Prior to 3.15.0, the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint calls _validate_webhook_url() in mlflow/utils/validation.py only for the original URL while mlflow/webhooks/delivery.py follows redirects and re-resolves the hostname without pinning the validated address, allowing attackers to reach internal or cloud metadata services and receive response_status and response_body. This issue is fixed in version 3.15.0.

Exploitation Scenario

An attacker finds an internet-exposed MLflow tracking server (common in AI/ML teams that stand up MLflow for convenience without hardening it). They call the unauthenticated `POST /api/2.0/mlflow/webhooks/{id}/test` endpoint with a webhook URL pointing to an attacker-controlled domain that passes the initial `_validate_webhook_url()` check (e.g., a public, allowed-looking host). That domain responds with an HTTP redirect to `http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>`. MLflow's delivery code follows the redirect without re-validating the new destination, fetches the cloud metadata response, and returns `response_status`/`response_body` directly to the attacker — handing over temporary IAM credentials for the instance's role. The attacker then uses those credentials to enumerate and access cloud resources (S3 buckets with training data/model artifacts, other internal APIs), escalating from a single misconfigured webhook feature to broader cloud account compromise.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.