CVE-2026-71211 Overview
CVE-2026-71211 is a Server-Side Request Forgery (SSRF) vulnerability in MLflow's AI Gateway component. The flaw resides in the gateway secret creation flow, which accepts an auth_config.api_base value without validating scheme, host, or IP range. The gateway proxy endpoint then issues HTTP requests to the stored destination and returns the full response body to the caller. The CreateGatewaySecret action is missing from the permission-validator map, so any authenticated user — including read-only accounts — can abuse the proxy to reach internal addresses. The vulnerability is tracked under [CWE-918] and carries a CVSS 3.1 base score of 7.1.
Critical Impact
Any authenticated MLflow user can pivot the gateway proxy to cloud metadata endpoints and internal services, potentially exfiltrating IAM credentials.
Affected Products
- MLflow AI Gateway (see mlflow/server/handlers.py and mlflow/server/gateway_api.py)
- MLflow v3.14.0 source tree referenced in the disclosure
- Deployments exposing the gateway secret and proxy endpoints to authenticated users
Discovery Timeline
- 2026-08-05 - CVE-2026-71211 published to NVD
- 2026-08-05 - Last updated in NVD database
Technical Details for CVE-2026-71211
Vulnerability Analysis
MLflow's AI Gateway exposes a secret-management flow that stores upstream provider configuration for LLM routes. The _create_gateway_secret handler in mlflow/server/handlers.py accepts an auth_config.api_base string and persists it verbatim. No validation restricts the URL scheme, resolves the host, or rejects private, loopback, or link-local address ranges.
The proxy endpoint raw_proxy in mlflow/server/gateway_api.py reads the stored api_base, appends a caller-supplied path, issues an outbound HTTP request, and returns the full response body to the caller. This turns the MLflow server into a confused deputy that reaches destinations of the attacker's choosing.
MLflow already ships an SSRF guard, _validate_webhook_url, which blocks non-global and metadata IPs. That helper is never called on the gateway secret or proxy code path, leaving the destination unvalidated end to end.
A related fix, CVE-2026-4035, addressed a separate leak in the same feature where $ENV_VAR resolution inside api_key exposed credentials to the configured upstream. That patch does not touch the api_base destination and therefore does not close this gap.
Root Cause
The root cause is missing input validation on the api_base field combined with a missing authorization entry. The CreateGatewaySecret action has no entry in the permission-validator map, so it falls back to basic authentication rather than requiring a privileged scope. Read-only accounts inherit the ability to create secrets.
Attack Vector
An authenticated attacker calls the gateway secret creation API with auth_config.api_base set to an internal target such as http://169.254.169.254/. The attacker then calls the gateway proxy endpoint with a path segment that completes the metadata service URL. The MLflow server issues the request and returns the metadata response, including any IAM role credentials exposed by the cloud provider.
The vulnerability manifests in _create_gateway_secret and raw_proxy. See the MLflow source tree for the affected handlers.
Detection Methods for CVE-2026-71211
Indicators of Compromise
- Gateway secret creation requests where auth_config.api_base points to RFC 1918, loopback, link-local, or cloud metadata addresses such as 169.254.169.254, 100.100.100.200, or metadata.google.internal.
- Outbound HTTP requests from the MLflow server process to internal or metadata endpoints correlated with /gateway/ proxy traffic.
- Gateway proxy responses containing IAM credential fields such as AccessKeyId, SecretAccessKey, or Token.
Detection Strategies
- Inspect MLflow audit logs for CreateGatewaySecret calls originating from read-only or service accounts that should not manage gateway configuration.
- Alert on any egress from MLflow server hosts to link-local address ranges or cloud provider metadata IPs.
- Baseline the set of legitimate api_base hostnames and flag new entries that do not resolve to the expected LLM provider domains.
Monitoring Recommendations
- Enable request/response logging on the gateway proxy endpoint and retain payloads for retrospective analysis.
- Monitor cloud IAM activity for use of the MLflow instance role from unexpected principals or regions.
- Correlate gateway secret write events with subsequent raw_proxy invocations against the same secret within short time windows.
How to Mitigate CVE-2026-71211
Immediate Actions Required
- Restrict network egress from MLflow servers so they cannot reach cloud metadata endpoints or internal management ranges.
- Apply IMDSv2 with hop-limit 1 on AWS, or the equivalent metadata hardening on Azure and GCP, to block proxy-based credential theft.
- Revoke gateway secret creation privileges from read-only and general user accounts until a fix is deployed.
- Rotate any IAM credentials associated with the MLflow instance role if abuse is suspected.
Patch Information
No fixed version is listed in the NVD entry for CVE-2026-71211 at time of publication. Track the MLflow repository for updates that add scheme/host validation to _create_gateway_secret and register CreateGatewaySecret in the permission-validator map.
Workarounds
- Place MLflow behind a reverse proxy that strips or rewrites outbound requests originating from the gateway proxy endpoint.
- Disable the AI Gateway feature entirely if it is not required in the deployment.
- Enforce network policy that denies MLflow pod or host access to 169.254.0.0/16, 127.0.0.0/8, and RFC 1918 ranges except where explicitly needed.
- Require an authenticating egress proxy with an allowlist of legitimate upstream LLM provider domains for all MLflow outbound traffic.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
