CVE-2026-71211: MLflow SSRF via unvalidated api_base

Q: Is CVE-2026-71211 actively exploited?

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

Q: How to fix CVE-2026-71211?

1) Patch to the MLflow release that validates auth_config.api_base scheme/host/IP range once available (track upstream github.com/mlflow/mlflow for the fix). 2) In the interim, restrict who can create/edit AI Gateway secrets to trusted admins only — this vulnerability requires an authenticated low-privilege account. 3) Apply network egress controls on the MLflow host/container: block outbound access to cloud metadata IPs (169.254.169.254, metadata.google.internal), RFC1918 internal ranges not required by the gateway, and any other sensitive internal services. 4) If running in AWS/GCP/Azure, enforce IMDSv2 (or equivalent) and use least-privilege IAM roles on the MLflow host so a metadata-endpoint SSRF yields minimal value. 5) Detection: monitor MLflow gateway secret creation events and raw_proxy request logs for unexpected or internal-looking api_base/path values, and alert on outbound connections from the MLflow host to non-allowlisted destinations.

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

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM gateway / proxy, ml_ops pipelines, cloud-hosted ML infrastructure.

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

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

CISO Take

MLflow's AI Gateway lets a low-privileged user store an arbitrary api_base value when creating a gateway secret, and the server later uses that stored value verbatim to make outbound HTTP requests through its raw_proxy endpoint, returning the full response body to the caller — a textbook server-side request forgery. This matters because MLflow tracking servers typically run inside cloud VPCs with network access to internal-only services, admin panels, and cloud instance metadata endpoints, so an attacker with only low privileges (PR:L, CVSS 7.1, C:H/I:L) could pivot through the gateway to steal cloud IAM credentials or read internal API responses with no user interaction required. The EPSS score is currently very low (0.17%), there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA's SSVC decision is TRACK — so this is not an actively-exploited or urgent-patch situation today, but the SSRF pattern is trivial to weaponize once a PoC surfaces. Restrict who can create AI Gateway secrets, egress-filter the MLflow host so it cannot reach cloud metadata IPs (169.254.169.254) or internal management networks, upgrade to the patched MLflow release once available, and monitor outbound requests from the MLflow server for unexpected destinations in the meantime.

Sources: NVD EPSS ATLAS

What is the risk?

Moderate-to-high technical severity (CVSS 7.1, network-exploitable, low complexity, no user interaction) offset by low current exploitation pressure: EPSS is only 0.17%, there is no public exploit code or scanner template, the CVE is not in CISA KEV, and CISA's own SSVC decision is TRACK (lowest urgency tier). The main risk driver is not 'is this being exploited' but 'what does the SSRF reach' — in environments where the MLflow server has network access to cloud metadata services or internal admin systems, a successful exploit converts a low-privilege application account into a credential-theft or internal-recon primitive. Requires PR:L (an existing low-privilege account), which limits exposure to insiders, compromised low-priv credentials, or multi-tenant MLflow deployments rather than fully unauthenticated internet-wide attackers.

How does the attack unfold?

Malicious Secret Configuration

An authenticated low-privilege user creates an AI Gateway secret with auth_config.api_base pointing to an internal or cloud-metadata target, which MLflow stores without validating scheme, host, or IP range.

AML.T0049

SSRF Proxy Trigger

The attacker calls the raw_proxy endpoint with a caller-supplied path, causing the MLflow server to issue an outbound HTTP request to the stored api_base target on their behalf.

AML.T0006

Response Exfiltration

MLflow returns the full HTTP response body to the attacker, exposing cloud IAM credentials, internal API data, or admin interface content that was otherwise unreachable.

AML.T0075

Credential Abuse / Lateral Movement

The attacker uses stolen cloud credentials or internal data to pivot further into cloud infrastructure or the ML pipeline, escalating a single-host bug into broader compromise.

Malicious Secret Configuration

An authenticated low-privilege user creates an AI Gateway secret with auth_config.api_base pointing to an internal or cloud-metadata target, which MLflow stores without validating scheme, host, or IP range.

AML.T0049

SSRF Proxy Trigger

The attacker calls the raw_proxy endpoint with a caller-supplied path, causing the MLflow server to issue an outbound HTTP request to the stored api_base target on their behalf.

AML.T0006

Response Exfiltration

MLflow returns the full HTTP response body to the attacker, exposing cloud IAM credentials, internal API data, or admin interface content that was otherwise unreachable.

AML.T0075

Credential Abuse / Lateral Movement

The attacker uses stolen cloud credentials or internal data to pivot further into cloud infrastructure or the ML pipeline, escalating a single-host bug into broader compromise.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MLflow	pip	>= 3.13.0, <= 3.15.2	No patch
28.0K OpenSSF 5.4 690 dependents Pushed 2d ago 36% patched ~73d 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 17% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I Low

A None

What should I do?

1 step

1) Patch to the MLflow release that validates auth_config.api_base scheme/host/IP range once available (track upstream github.com/mlflow/mlflow for the fix). 2) In the interim, restrict who can create/edit AI Gateway secrets to trusted admins only — this vulnerability requires an authenticated low-privilege account. 3) Apply network egress controls on the MLflow host/container: block outbound access to cloud metadata IPs (169.254.169.254, metadata.google.internal), RFC1918 internal ranges not required by the gateway, and any other sensitive internal services. 4) If running in AWS/GCP/Azure, enforce IMDSv2 (or equivalent) and use least-privilege IAM roles on the MLflow host so a metadata-endpoint SSRF yields minimal value. 5) Detection: monitor MLflow gateway secret creation events and raw_proxy request logs for unexpected or internal-looking api_base/path values, and alert on outbound connections from the MLflow host to non-allowlisted destinations.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Data Leakage Auth Bypass API Framework Inference AML.T0006 - Active Scanning 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.6.2.6 - AI system deployment and operational security

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

Frequently Asked Questions

What is CVE-2026-71211?

MLflow's AI Gateway lets a low-privileged user store an arbitrary api_base value when creating a gateway secret, and the server later uses that stored value verbatim to make outbound HTTP requests through its raw_proxy endpoint, returning the full response body to the caller — a textbook server-side request forgery. This matters because MLflow tracking servers typically run inside cloud VPCs with network access to internal-only services, admin panels, and cloud instance metadata endpoints, so an attacker with only low privileges (PR:L, CVSS 7.1, C:H/I:L) could pivot through the gateway to steal cloud IAM credentials or read internal API responses with no user interaction required. The EPSS score is currently very low (0.17%), there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA's SSVC decision is TRACK — so this is not an actively-exploited or urgent-patch situation today, but the SSRF pattern is trivial to weaponize once a PoC surfaces. Restrict who can create AI Gateway secrets, egress-filter the MLflow host so it cannot reach cloud metadata IPs (169.254.169.254) or internal management networks, upgrade to the patched MLflow release once available, and monitor outbound requests from the MLflow server for unexpected destinations in the meantime.

Is CVE-2026-71211 actively exploited?

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

How to fix CVE-2026-71211?

1) Patch to the MLflow release that validates auth_config.api_base scheme/host/IP range once available (track upstream github.com/mlflow/mlflow for the fix). 2) In the interim, restrict who can create/edit AI Gateway secrets to trusted admins only — this vulnerability requires an authenticated low-privilege account. 3) Apply network egress controls on the MLflow host/container: block outbound access to cloud metadata IPs (169.254.169.254, metadata.google.internal), RFC1918 internal ranges not required by the gateway, and any other sensitive internal services. 4) If running in AWS/GCP/Azure, enforce IMDSv2 (or equivalent) and use least-privilege IAM roles on the MLflow host so a metadata-endpoint SSRF yields minimal value. 5) Detection: monitor MLflow gateway secret creation events and raw_proxy request logs for unexpected or internal-looking api_base/path values, and alert on outbound connections from the MLflow host to non-allowlisted destinations.

What systems are affected by CVE-2026-71211?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM gateway / proxy, ml_ops pipelines, cloud-hosted ML infrastructure.

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

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

What is the AI security impact?

Affected AI Architectures

model servingLLM gateway / proxyml_ops pipelinescloud-hosted ML infrastructure

MITRE ATLAS Techniques

AML.T0006 Active Scanning

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

MLflow's AI Gateway accepts an auth_config.api_base value when creating a gateway secret (mlflow/server/handlers.py, _create_gateway_secret) with no validation of scheme, host, or IP range; the value is stored verbatim. The gateway proxy endpoint (mlflow/server/gateway_api.py, raw_proxy) subsequently issues an HTTP request to that stored api_base plus a caller-supplied path and returns the full response body.

Exploitation Scenario

An attacker who holds (or has compromised) a low-privileged MLflow account calls _create_gateway_secret with auth_config.api_base set to an internal target — for example the cloud instance metadata service (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>) or an internal admin API only reachable from the MLflow host's network segment. They then invoke the raw_proxy endpoint with a caller-supplied path, causing the MLflow server to issue the HTTP request on their behalf and return the full response body — handing the attacker cloud IAM credentials or internal service data they could never reach directly. Those stolen credentials or data can then be used for lateral movement, further cloud resource compromise, or exfiltration of proprietary ML artifacts.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF) 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.