Introduction
An authentication bypass in MLflow's FastAPI middleware allows unauthenticated remote attackers to submit jobs, read job results, cancel running jobs, and inject arbitrary trace data into experiments, all on servers that were explicitly configured with authentication enabled. The vulnerability, CVE-2026-2652, carries a CVSS score of 8.6 (High) and affects MLflow versions 3.9.0 and earlier when served via uvicorn.
MLflow is an open source platform for managing the end to end machine learning lifecycle, encompassing experiment tracking, model packaging, deployment, and a central model registry. It is one of the most widely adopted MLOps tools in the industry, used across organizations of all sizes. Its role as a central hub for ML workflows makes authentication bypasses particularly consequential, as they can expose model training data, job configurations, and operational pipelines.
Technical Information
Root Cause: Flask vs. FastAPI Authentication Mismatch
The core issue is an architectural impedance mismatch between Flask and FastAPI within the MLflow server. Flask routes are protected by a request interceptor that runs on every incoming request. FastAPI routes, however, bypass Flask entirely and rely on a separate permission middleware.
This FastAPI middleware uses a validator lookup function named _find_fastapi_validator() to determine which authentication check to apply to a given request. In affected versions, this function only recognizes paths under /gateway/. When a request targets any non gateway FastAPI route, the validator returns a null value. The middleware then interprets this as "no authentication required" and passes the request through without any checks.
This is a textbook example of CWE-305 (Authentication Bypass by Primary Weakness): the system has an authentication mechanism in place, but a flaw in its implementation allows it to be completely circumvented for specific routes.
Affected Endpoints and Attacker Capabilities
The following FastAPI routes are left unprotected by the middleware:
| Endpoint | HTTP Method | Attacker Capability |
|---|---|---|
| /ajax-api/3.0/jobs/ | POST | Submit jobs and invoke scorers using server gateway API keys |
| /ajax-api/3.0/jobs/{job_id} | GET | Read results and parameters of any job |
| /ajax-api/3.0/jobs/search | POST | Enumerate all jobs on the server |
| /ajax-api/3.0/jobs/cancel/{job_id} | PATCH | Cancel any running job, causing denial of service |
| /v1/traces | POST | Inject arbitrary trace and span data into any experiment |
Attack Flow
Exploitation is straightforward and requires no privileges, no user interaction, and no special tooling:
- The attacker identifies an MLflow server that is network accessible and configured with
--app-name basic-authserved via uvicorn (ASGI). - The attacker sends an unauthenticated POST request to
/ajax-api/3.0/jobs/searchwith an empty JSON payload. - The request hits the FastAPI permission middleware. The middleware calls
_find_fastapi_validator()with the request path. - Because the path does not start with
/gateway/, the function returns null. - The middleware receives the null validator and allows the request to proceed without authentication.
- The server processes the request and returns a full listing of all jobs, including their parameters and results.
From there, the attacker can escalate by submitting new jobs (which may invoke scorers using the server's own gateway API keys), canceling running jobs to disrupt operations, or injecting fabricated trace data into experiments via the /v1/traces endpoint to corrupt observability data.
Fix in Version 3.10.0
The upstream patch (commit bb62e77) updates _find_fastapi_validator() to handle all FastAPI routes, not just gateway paths. Specific validators are added for the trace ingestion and job APIs. The fix also introduces comprehensive tests that verify unauthenticated access attempts to these endpoints return a 401 Unauthorized status code, establishing a regression safety net.
Affected Systems and Versions
The vulnerability affects MLflow versions 3.9.0 and earlier under the following specific configuration:
- MLflow server started with authentication enabled using the
--app-name basic-authflag - Server served via uvicorn (ASGI mode)
Deployments that do not use the basic auth app name, or that are served through a different WSGI/ASGI server configuration, may not be affected in the same way, though the underlying code flaw is present in all versions prior to 3.10.0.
The fix is included in MLflow version 3.10.0.



