MLflow is the experiment tracker and model registry a lot of teams reach for
when they want MLOps without handing the whole thing to a vendor. It sits in
the MLOps corner of the [self-hosted AI landscape](/guides/self-hosted-ai-landscape-2026),
and it is also, structurally, a system that was not designed auth-first —
permissions arrived as a plugin bolted onto an already-open API surface. In
2026 that history produced three authorization and secrets CVEs, one of them
critical. If your MLflow is reachable by anyone other than you, the short
version is: get to 3.14.0 and stop exposing --serve-artifacts.
## Authenticated, but not authorized per resource
Read the three advisories together and the same shape repeats. MLflow can authenticate a request — it knows who you are — but individual endpoints do not consistently check whether you are allowed to touch the specific resource you named. That is authentication without resource-level authorization. Every time a new feature landed — artifact proxying, tracing, the AI Gateway — it shipped without wiring into the permission model the auth plugin was meant to enforce. The result is a registry where being logged in sits uncomfortably close to being an admin of everyone else's data.
## CVE-2026-2651 — artifact overwrite, critical (9.0)
Act on this one first. With --serve-artifacts enabled, MLflow proxies
artifact storage through its own process. The multipart-upload (MPU) endpoints
under /mlflow-artifacts/mpu/* do not enforce resource-level permission
checks. An attacker who can reach those endpoints can overwrite artifacts that
belong to other experiments and other users — model weights, serialized
pipelines, evaluation outputs. Affected versions are up to and including
3.10.1.dev0.
The reason this rates a 9.0 rather than a defacement footnote is the supply-chain tail. If your deployment or serving pipeline pulls "the latest model artifact" from the registry and runs it, overwriting that artifact is a path to attacker-chosen code executing downstream. The verb is overwrite, not read — this mutates the thing other systems trust.
## CVE-2026-8147 — the trace API skips authorization, high (8.1)
MLflow's tracing feature stores request and response traces against experiments. With authentication enabled — so you would reasonably assume access is controlled — the trace API endpoints have no authorization validators. Any authenticated user can read, delete, and modify traces on experiments they do not own.
In a shared MLflow, that means every account with a login can read every other tenant's traces. Traces routinely contain prompts, inputs, and model outputs you never intended to share across teams, and the same gap lets a user delete or tamper with them. It is fixed in 3.14.0. Note that "we turned auth on" does not help here — auth was on and the endpoint still did not care whose experiment it was.
## CVE-2026-4035 — the AI Gateway leaks server env vars, high (7.7)
The AI Gateway is MLflow's LLM routing layer, and it lets you configure
provider secrets. Its secret handling resolves environment variables in the
api_key field. That indirection is abusable: an attacker who can define or
edit a gateway route points api_key at a server-side environment variable
and directs the call to an endpoint they control, exfiltrating whatever
credential lived in that variable — cloud keys, other providers' tokens,
database URLs. The gateway becomes a read primitive for the host's entire
environment. It is fixed in 3.11.0. If your gateway was ever exposed, assume
the environment it ran in is now known to someone else.
## What to do right now
- Upgrade to 3.14.0 or later. That single floor closes all three: the
- Do not run `--serve-artifacts` on an exposed instance. If you need
- **Put MLflow behind an authenticating reverse proxy with network
- **Rotate every credential that lived in the environment of an exposed AI
- Treat MLflow as an internal-only service. The same conclusion we reach
## Takeaway
MLflow is genuinely useful and the fix is boring: 3.14.0, off the public internet, credentials rotated if the gateway was ever reachable. The part worth remembering is the pattern. A tool that authenticates but does not authorize per resource keeps producing this class of bug as it grows features, and MLflow has now done it three times in a single year — artifacts, traces, gateway secrets. Patch it, isolate it, and do not let "it has a login page" stand in for access control. The live feed is at [/cves](/cves); if you want to know whether your own compose file pulls in an affected version, the [scanner](/scanner) will tell you.