MLflow CVE-2026-3198

MLflow must be deployed with the basic-auth plugin explicitly enabled via the --app-name basic-auth launch flag - the vulnerability does not exist in default MLflow deployments without this flag. The attacker must hold a valid MLflow credential (any permission tier); CVSS PR:L confirms low-privilege authentication is sufficient, and unauthenticated access does not trigger the bypass. The Gateway API feature must be in use and must contain configured secrets, endpoints, or model definitions - an empty gateway exposes no sensitive data even if the authorization gap exists. Exploitation is limited to confidentiality: no write, delete, or code execution primitives are exposed by these list endpoints. The vulnerability does not affect non-Gateway MLflow API routes, as those handlers are correctly registered in BEFORE_REQUEST_HANDLERS.

The CVSS 6.5 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) accurately reflects the threat model: network-reachable, trivially exploitable by any authenticated user, with high confidentiality impact and no integrity or availability effect. The PR:L vector confirms that a valid (even low-privilege) account is required - unauthenticated exploitation is not possible per available CVSS data. Attack complexity is low (AC:L), meaning no race conditions, special timing, or environmental prerequisites beyond authentication. No EPSS score was provided in the input data, and the vulnerability is not in CISA KEV, indicating no confirmed active exploitation at time of analysis. No public proof-of-concept code has been identified. Despite the absence of active exploitation signals, the high confidentiality impact is operationally significant: exposed gateway secrets likely include third-party AI provider API keys (e.g., OpenAI, Anthropic), which carry financial and data-access risk well beyond the MLflow deployment itself. Organizations running MLflow with multiple user tiers (admin vs. read-only) are most exposed, as the vulnerability nullifies the access segregation they may have implemented.

An attacker with a low-privilege MLflow account - such as a data scientist or analyst in a shared MLflow deployment - authenticates normally, then sends standard HTTP GET requests to the ListGatewaySecretInfos, ListGatewayEndpoints, and ListGatewayModelDefinitions Gateway API endpoints. Because these routes are absent from the authorization handler registry, MLflow returns the full response without checking whether the user's assigned permissions allow access, exposing all stored API keys (e.g., provider credentials for OpenAI or Anthropic), endpoint routing configurations, and proprietary model definitions to the attacker. No special tooling is required beyond a standard HTTP client; no public proof-of-concept has been identified, but the attack is straightforward to replicate from the description alone.