CVE-2026-2393: MLflow: SSRF in webhook URL enables cloud credential theft

GHSA-65h7-c7c4-mghx HIGH CISA: TRACK*
Published May 11, 2026
CISO Take

CVE-2026-2393 is a Server-Side Request Forgery vulnerability in MLflow's webhook registration endpoint that allows any authenticated user to force the MLflow backend to make arbitrary HTTP requests — including to cloud instance metadata services (AWS IMDSv1 at 169.254.169.254, GCP metadata endpoint) that vend temporary IAM credentials. In typical enterprise ML environments, MLflow runs with broad cloud permissions to access S3/GCS artifact storage, model registries, and GPU compute, meaning credential theft via IMDS translates directly to a blast radius spanning the entire ML infrastructure account. No public exploit exists yet and CVSS scoring is pending, but SSRF-to-IMDS is a thoroughly documented, low-complexity attack requiring only a valid MLflow account — making the barrier to exploitation trivially low for any insider or attacker with stolen credentials. Upgrade to MLflow 3.9.0 immediately; as a compensating control, block outbound HTTP from the MLflow host to 169.254.169.254 and RFC 1918 ranges, enable AWS IMDSv2 on EC2 instances, and audit all existing webhook registrations for suspicious URLs.

Sources: NVD GitHub Advisory ATLAS huntr.com

What is the risk?

High risk for cloud-hosted MLflow deployments. The attack requires only valid MLflow authentication — a low bar in environments where ML engineers, data scientists, and automated CI/CD pipelines all hold credentials. SSRF to cloud metadata endpoints (AWS IMDSv1, GCP v1 metadata) is a well-documented attack vector with no meaningful technical sophistication barrier. MLflow service accounts typically carry permissions far broader than the principle of least privilege would allow, compounding the credential-theft impact. On-premises deployments face lower but non-trivial risk through internal network reconnaissance and data exfiltration from internal APIs.

How does the attack unfold?

Initial Access
Attacker authenticates to the MLflow server using valid credentials obtained via phishing, credential stuffing, or insider access.
AML.T0012
Webhook Registration
Attacker calls the MLflow webhook creation API with a malicious URL targeting the cloud instance metadata service (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/).
AML.T0049
Credential Harvesting
MLflow's _send_webhook_request() issues an unauthenticated HTTP POST to the IMDS endpoint without URL validation, receiving temporary cloud IAM credentials in the response.
AML.T0106
Cloud Escalation & Exfiltration
Attacker uses harvested IAM credentials to access cloud storage buckets, model registries, and compute resources, exfiltrating ML training data and model artifacts.
AML.T0025

What systems are affected?

Package Ecosystem Vulnerable Range Patched
MLflow pip < 3.9.0 3.9.0
26.7K OpenSSF 5.4 655 dependents Pushed 6d ago 31% patched ~76d to patch Full package profile →

Do you use MLflow? You're affected.

How severe is it?

CVSS 3.1
7.1 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 21% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
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 AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I Low
A None

What should I do?

1 step
  1. 1) Patch to MLflow 3.9.0 (fix commit: github.com/mlflow/mlflow/commit/64aa0ab7207f9c649b59ba1a5f40d82196817389). 2) Immediate compensating control: block outbound HTTP/HTTPS from the MLflow host to 169.254.169.254 (AWS/GCP IMDS), 100.64.169.254 (GCP alternate IMDS), and RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) via host firewall or cloud security groups. 3) Enable IMDSv2 on all AWS EC2 instances hosting MLflow — IMDSv2 requires a PUT-initiated session token that standard SSRF payloads cannot obtain. 4) Audit all registered webhooks: query the MLflow webhooks API or registry_webhooks table and review all URLs for suspicious destinations. 5) Apply least-privilege to MLflow service accounts and remove permissions not required for core functionality. 6) Monitor MLflow server outbound network connections for anomalous destinations via VPC flow logs or host-level network monitoring.

What does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.8.4 - Information security in AI system operations
NIST AI RMF
MG-2.4 - Residual risks and vulnerabilities are monitored and managed
OWASP LLM Top 10
LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-2393?

CVE-2026-2393 is a Server-Side Request Forgery vulnerability in MLflow's webhook registration endpoint that allows any authenticated user to force the MLflow backend to make arbitrary HTTP requests — including to cloud instance metadata services (AWS IMDSv1 at 169.254.169.254, GCP metadata endpoint) that vend temporary IAM credentials. In typical enterprise ML environments, MLflow runs with broad cloud permissions to access S3/GCS artifact storage, model registries, and GPU compute, meaning credential theft via IMDS translates directly to a blast radius spanning the entire ML infrastructure account. No public exploit exists yet and CVSS scoring is pending, but SSRF-to-IMDS is a thoroughly documented, low-complexity attack requiring only a valid MLflow account — making the barrier to exploitation trivially low for any insider or attacker with stolen credentials. Upgrade to MLflow 3.9.0 immediately; as a compensating control, block outbound HTTP from the MLflow host to 169.254.169.254 and RFC 1918 ranges, enable AWS IMDSv2 on EC2 instances, and audit all existing webhook registrations for suspicious URLs.

Is CVE-2026-2393 actively exploited?

No confirmed active exploitation of CVE-2026-2393 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-2393?

1) Patch to MLflow 3.9.0 (fix commit: github.com/mlflow/mlflow/commit/64aa0ab7207f9c649b59ba1a5f40d82196817389). 2) Immediate compensating control: block outbound HTTP/HTTPS from the MLflow host to 169.254.169.254 (AWS/GCP IMDS), 100.64.169.254 (GCP alternate IMDS), and RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) via host firewall or cloud security groups. 3) Enable IMDSv2 on all AWS EC2 instances hosting MLflow — IMDSv2 requires a PUT-initiated session token that standard SSRF payloads cannot obtain. 4) Audit all registered webhooks: query the MLflow webhooks API or registry_webhooks table and review all URLs for suspicious destinations. 5) Apply least-privilege to MLflow service accounts and remove permissions not required for core functionality. 6) Monitor MLflow server outbound network connections for anomalous destinations via VPC flow logs or host-level network monitoring.

What systems are affected by CVE-2026-2393?

This vulnerability affects the following AI/ML architecture patterns: ML training pipelines, MLOps experiment tracking environments, Model registry deployments, Cloud-hosted ML infrastructure.

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

CVE-2026-2393 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.29%.

What is the AI security impact?

Affected AI Architectures

ML training pipelinesMLOps experiment tracking environmentsModel registry deploymentsCloud-hosted ML infrastructure

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means
AML.T0049 Exploit Public-Facing Application
AML.T0075 Cloud Service Discovery
AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.8.4
NIST AI RMF: MG-2.4
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A Server-Side Request Forgery (SSRF) vulnerability exists in MLflow versions prior to 3.9.0. The `_create_webhook()` function in `mlflow/server/handlers.py` accepts a user-controlled `url` parameter without validation, and the `_send_webhook_request()` function in `mlflow/webhooks/delivery.py` sends HTTP POST requests to this attacker-controlled URL. This allows an authenticated attacker to force the MLflow backend to send HTTP requests to internal services, cloud metadata endpoints, or arbitrary external servers. The lack of input sanitization, URL scheme filtering, or allowlist validation on the webhook URL enables exploitation, potentially leading to cloud credential theft, internal network access, and data exfiltration.

Exploitation Scenario

An attacker with valid MLflow credentials (obtained via phishing, credential stuffing, or insider access) registers a webhook via POST /api/2.0/mlflow/registry-webhooks/create, setting the URL to http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]. When any registry event fires the webhook, MLflow's _send_webhook_request() in delivery.py issues an HTTP POST to the AWS IMDS endpoint and receives a JSON response containing a temporary AccessKeyId, SecretAccessKey, and SessionToken. The attacker extracts these credentials from webhook delivery metadata, response logs, or timing side-channels, then uses them with the AWS CLI to enumerate and exfiltrate training datasets from S3, steal model artifacts from SageMaker, or pivot laterally across the cloud account — potentially reaching production model serving infrastructure.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Timeline

Published
May 11, 2026
Last Modified
May 18, 2026
First Seen
May 11, 2026

Related Vulnerabilities