MLflow server without login? Two flaws read files and run code

If your team runs an MLflow server to track experiments and models, and someone can reach that server over the network without signing in, two flaws let them read the server's files or run code on it. Here you will find out what version 3.17.0 fixed, who is exposed, and what to do today.

Which flaws did MLflow 3.17.0 fix?

MLflow is an open source platform for tracking machine learning experiments and registering models. On October 27, 2026 three of its security advisories were added to the GitHub Advisory Database after review, all fixed in 3.17.0:

The scores are CVSS 3.1. The advisories themselves were published earlier in the MLflow repository, between October 9 and October 13, 2026.

How does an attacker read the server's files?

CVE-2026-116690 lets a remote attacker read any file the MLflow server process can reach, on a tracking server without authentication. The advisory says that is the default for mlflow server.

The attacker creates a model version tagged as a prompt whose source is a local path with no scheme. The code did not validate such a path in the prompt branch, and the get-artifact endpoint then serves the file with the server's privileges.

The advisory gives examples: /etc/passwd, the SQLite authentication and tracking databases, and shell history files. On a server running with --app-name basic-auth, any signed-in user who can create a registered model can read the authentication database, including the admin password hash.

How does an attacker get to code execution?

CVE-2026-116692 lets an attacker with HTTP access run Python code as the MLflow server process. It started with third-party scorer support in 3.12.0.

The server accepted a Python module path in the request if it started with one of four allowed package prefixes, and imported it. The check accepted any module below those packages, so according to the advisory the chain goes like this:

1. The attacker creates an experiment whose artifact location points into a writable allowed scorer package.

2. They create a run, which allocates an artifact directory inside that package.

3. They upload a Python module into that directory.

4. They submit a serialized scorer that references the uploaded module.

5. They call the scorer invocation endpoint, and the server imports and runs the module.

The code runs before the server finishes the request, so it executes even if the request fails later. In the stock image used for the reproduction, the server runs as uid 0. The condition is that the server can write beneath an allowed scorer package; a read-only container filesystem blocks this path.

Why are LLM keys at risk too?

Because mlflow.crewai.autolog() copied CrewAI's LLM provider keys into trace data without being asked to (CVE-2026-116691). Anyone with access to the trace storage, or to the OTLP destination it exports to, gets the key.

The update does not remove what was already written. The advisory says to rotate any provider key held by a CrewAI LLM while autologging was on, and to delete or redact the affected traces. We covered keys leaking out of an AI tool before with the LiteLLM compromise.

If you need to rotate several keys in a row, the steps for rotating secrets after a leak are in our article on the Railway breach.

Where do you start now?

Start with the version, then with who can reach the server without an account.

1. Run pip show mlflow on the server and check the version.

2. Update to 3.17.0 or later.

3. If the server is open without login, put it behind authentication or an internal network, since the file read and code execution work without an account.

4. If you use CrewAI autologging, rotate the provider keys and clean the traces. If you can't update, turn it off with mlflow.crewai.autolog(disable=True).

5. Run the MLflow container with a read-only filesystem if you can.

If you have internal tools like MLflow open to the internet and want to know what an attacker sees in them, that is the job of Muhassan.

All our AI articles are in one place: AI articles.