CVE-2026-3198: MLflow: auth bypass exposes gateway secrets and keys
GHSA-r5m9-wm49-959f MEDIUM CISA: TRACK*MLflow 3.9.0's basic-auth plugin omits authorization checks for three Gateway API list endpoints — ListGatewaySecretInfos, ListGatewayEndpoints, and ListGatewayModelDefinitions — meaning any authenticated user, regardless of assigned role, can enumerate all stored API keys, endpoint configurations, and proprietary model definitions. In production MLOps environments where the MLflow Gateway proxies requests to LLM providers like OpenAI or Anthropic, this collapses the intended RBAC model: a single compromised or malicious low-privilege account yields all secrets needed to directly query those providers outside of any internal control plane. No CVSS score or EPSS data is yet available and the vulnerability is not in CISA KEV, but the trivially low exploitation bar — authenticated API calls only — elevates practical risk wherever gateway secrets contain live LLM API keys. Rotate all MLflow Gateway secrets immediately, restrict network access to the Gateway API to trusted networks, and monitor for patch availability in the MLflow GitHub releases.
What is the risk?
Medium-High practical risk despite absent CVSS scoring. Exploitation requires only a valid MLflow account — no privilege escalation, no novel exploit chain, no special tooling. The critical factor is blast radius: organizations using MLflow Gateway to centralize LLM API key management (a common pattern for cost control and observability) face complete secret exfiltration from a single low-privilege account. Multi-tenant or shared MLflow deployments used across data science teams dramatically increase the exposure surface, as any user on the platform becomes a viable threat actor.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| MLflow | pip | < 3.11.0rc0 | 3.11.0rc0 |
Do you use MLflow? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Upgrade to a patched MLflow release as soon as available — track the GitHub releases page and the huntr.com advisory (https://huntr.com/bounties/e57db731-97d3-40c3-a429-831ee959807f).
-
Immediately rotate all API keys stored as MLflow Gateway secrets; re-issue only to services that require them with scoped permissions.
-
As an immediate workaround, restrict network-level access to the MLflow Gateway API endpoints (/gateway/*) to trusted IP ranges using a reverse proxy or network policy — this does not fix the authorization gap but significantly reduces exposure surface.
-
Audit Gateway API access logs for ListGatewaySecretInfos and ListGatewayEndpoints calls made by non-admin users since the MLflow 3.9.0 deployment date.
-
Evaluate migrating API key storage to a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than MLflow Gateway secrets, regardless of this CVE, to reduce the blast radius of future MLflow vulnerabilities.
What does CISA's SSVC say?
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:
Frequently Asked Questions
What is CVE-2026-3198?
MLflow 3.9.0's basic-auth plugin omits authorization checks for three Gateway API list endpoints — ListGatewaySecretInfos, ListGatewayEndpoints, and ListGatewayModelDefinitions — meaning any authenticated user, regardless of assigned role, can enumerate all stored API keys, endpoint configurations, and proprietary model definitions. In production MLOps environments where the MLflow Gateway proxies requests to LLM providers like OpenAI or Anthropic, this collapses the intended RBAC model: a single compromised or malicious low-privilege account yields all secrets needed to directly query those providers outside of any internal control plane. No CVSS score or EPSS data is yet available and the vulnerability is not in CISA KEV, but the trivially low exploitation bar — authenticated API calls only — elevates practical risk wherever gateway secrets contain live LLM API keys. Rotate all MLflow Gateway secrets immediately, restrict network access to the Gateway API to trusted networks, and monitor for patch availability in the MLflow GitHub releases.
Is CVE-2026-3198 actively exploited?
No confirmed active exploitation of CVE-2026-3198 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-3198?
1. Upgrade to a patched MLflow release as soon as available — track the GitHub releases page and the huntr.com advisory (https://huntr.com/bounties/e57db731-97d3-40c3-a429-831ee959807f). 2. Immediately rotate all API keys stored as MLflow Gateway secrets; re-issue only to services that require them with scoped permissions. 3. As an immediate workaround, restrict network-level access to the MLflow Gateway API endpoints (/gateway/*) to trusted IP ranges using a reverse proxy or network policy — this does not fix the authorization gap but significantly reduces exposure surface. 4. Audit Gateway API access logs for ListGatewaySecretInfos and ListGatewayEndpoints calls made by non-admin users since the MLflow 3.9.0 deployment date. 5. Evaluate migrating API key storage to a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than MLflow Gateway secrets, regardless of this CVE, to reduce the blast radius of future MLflow vulnerabilities.
What systems are affected by CVE-2026-3198?
This vulnerability affects the following AI/ML architecture patterns: MLflow Gateway / AI Gateway deployments, MLOps platforms with multi-tenant access, LLM proxy and routing infrastructure, Model serving platforms, Centralized API key management for LLM providers.
What is the CVSS score for CVE-2026-3198?
CVE-2026-3198 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.24%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0007 Discover AI Artifacts AML.T0012 Valid Accounts AML.T0025 Exfiltration via Cyber Means AML.T0049 Exploit Public-Facing Application AML.T0055 Unsecured Credentials Compliance Controls Affected
What are the technical details?
Original Advisory
MLflow 3.9.0 with basic-auth (`--app-name basic-auth`) fails to enforce authorization checks for multiple Gateway API 'list' endpoints. Specifically, the `BEFORE_REQUEST_HANDLERS` dictionary in `mlflow/server/auth/__init__.py` does not include entries for `ListGatewaySecretInfos`, `ListGatewayEndpoints`, and `ListGatewayModelDefinitions`. This allows any authenticated user, regardless of their assigned permissions, to enumerate all gateway secrets, endpoints, and model definitions. This vulnerability exposes sensitive information, such as API keys, endpoint configurations, and proprietary model definitions, to unauthorized users.
Exploitation Scenario
An adversary with a low-privilege MLflow account — obtained via credential stuffing, phishing a junior data scientist, or compromising a CI/CD service account — authenticates to the MLflow Gateway API and issues a GET request to the ListGatewaySecretInfos endpoint. The request succeeds because the authorization handler is simply absent from the BEFORE_REQUEST_HANDLERS dictionary in mlflow/server/auth/__init__.py. The attacker receives a full list of stored API keys for all configured LLM providers (OpenAI, Anthropic, Azure OpenAI, etc.). They also call ListGatewayEndpoints to map the complete inference infrastructure — which models are deployed, their routing rules, and base URLs — and ListGatewayModelDefinitions to extract proprietary fine-tuned model configurations. Armed with harvested API keys, the adversary directly accesses LLM providers outside organizational controls, exfiltrating sensitive prompts, incurring unexpected API costs, or pivoting to other services sharing the same credentials.
Weaknesses (CWE)
CWE-284 Improper Access Control
Primary
CWE-284 Improper Access Control
Primary
CWE-284 Improper Access Control CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
- [Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2025-15379 10.0 MLflow: RCE via unsanitized model dependency specs
Same package: mlflow CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same package: mlflow CVE-2023-2780 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2023-1177 9.8 MLflow: path traversal allows arbitrary file read/write
Same package: mlflow CVE-2026-2635 9.8 mlflow: security flaw enables exploitation
Same package: mlflow