MLflow CVE-2026-116692: Unauthenticated RCE via Scorers

What to do

1. Check every tracking server: pip show mlflow, or docker exec <container> pip show mlflow; anything from 3.12.0rc0 up to 3.17.0 is affected.
2. Upgrade to 3.17.0 or later (pip install -U "mlflow>=3.17.0" or pull a 3.17.x image) and restart the server.
3. Until upgraded, take the server off untrusted networks and put it behind authentication (MLflow basic auth, a VPN or an identity-aware proxy).
4. Make the server's Python package tree read-only: run the container as a non-root user with a read-only root filesystem; the advisory says this blocks the chain.
5. If an affected server was reachable without authentication, run the checks below and rotate every credential the server process could read (artifact store keys, database URIs, cloud roles, LLM API keys).

How to check if you are affected or compromised

• Search access logs for POST /ajax-api/3.0/mlflow/scorer/invoke, especially from clients you do not recognize.
• List experiments with search_experiments(view_type=ViewType.ALL) and flag any whose artifact_location points into site-packages or the mlflow/genai/scorers package.
• Look for run-artifact directories or unexpected .py files inside the installed mlflow package tree, for example under mlflow/genai/scorers/.
• Check the server host or container for processes, outbound connections or files the MLflow service does not normally create.

What happened#

On October 27, MLflow published GHSA-26p8-2jq9-3vq9, assigned CVE-2026-116692 and scored CVSS 3.1 9.8 by GitHub, the CNA. MLflow 3.12.0 added support for registering and deserializing "third-party scorers", the evaluation plugins built on TruLens, Ragas, DeepEval and Phoenix. When the server deserializes a scorer, it takes a Python module path and class name from the request. It checks only that the module path begins with one of the allowed package names, then imports the module and instantiates the class.

A prefix is not a trust boundary. According to the advisory, an HTTP caller can chain built-in MLflow endpoints:

1. Create an experiment whose local artifact location points inside a writable allowed scorer package, such as mlflow/genai/scorers/trulens.
2. Create a run, which makes MLflow allocate <artifact_location>/<run_id>/artifacts/.
3. Upload a Python file as a run artifact.
4. Submit a serialized scorer whose module path resolves to that file.
5. Call /ajax-api/3.0/mlflow/scorer/invoke, which imports the file and runs its code inside the server process.

The reporter reproduced this on the official ghcr.io/mlflow/mlflow:v3.14.0 image with default settings. That image runs as uid 0 and lets the process write to its own package tree, so the result is unauthenticated arbitrary Python execution as root inside the container. The advisory includes a harmless proof of concept.

The fix, PR #25906, replaces the prefix match with an exact allow-list of 14 modules. It also requires the resolved class to be a Scorer subclass and rejects dotted metric names. It shipped in MLflow 3.17.0, which PyPI shows was released on October 7, three weeks before the advisory. The same release fixed two related scorer issues, including missing authorization on scorer/invoke (GHSA-6c27-cp6h-c66m).

Who is affected#

MLflow tracking servers from 3.12.0rc0 up to, but not including, 3.17.0. All three of these conditions must hold:

• Reachable: the attacker can send HTTP requests to the server. mlflow server binds to 127.0.0.1 by default, but shared team servers, Kubernetes deployments and Docker setups usually listen more widely.
• Allowed by authentication: with authentication off, the default, no credentials are needed. With basic auth on, the attacker needs an account that can create experiments and runs and upload artifacts, which on many shared servers is every user.
• Writable packages: the server process can write beneath an allowed scorer package. The official image allows this. A read-only container filesystem, or a package directory owned by another user, blocks the chain.

Using MLflow only as a client library, logging to a hosted or patched server, is not affected.

Do you really need to act?#

If you run a shared MLflow server in the affected range, yes, this week. No exploitation has been reported and CISA has not listed the CVE. However, the advisory documents the chain step by step, every step uses a normal MLflow API, and the default configuration of the official image meets every precondition. MLflow servers also tend to hold valuable secrets: artifact store keys, database URIs, cloud roles and, increasingly, LLM provider API keys. Attackers have exploited MLflow before. An unauthenticated SSRF, CVE-2026-64849, was added to CISA's KEV catalog on August 19, 2026.

A server that only binds to localhost on a developer laptop is a low priority. Exposed servers without authentication are not, and they should be patched today.

What to do now#

1. Check versions: pip show mlflow on the server host, or docker exec <container> pip show mlflow.
2. Upgrade: pip install -U "mlflow>=3.17.0", or move to a 3.17.x image, then restart. 3.17.2 is the current release.
3. Until upgraded, remove the server from untrusted networks and require authentication in front of it, using MLflow basic auth, a VPN or an identity-aware proxy.
4. Harden the deployment whatever version you run. Use a non-root user and a read-only root filesystem (docker run --read-only --user 1000:1000 ... with a separate writable volume for artifacts), so that uploaded files can never land inside importable code.
5. If an affected server was reachable without authentication, run the checks below and rotate the credentials the server process could read.

How to tell if you were hit#

• Search access logs for POST /ajax-api/3.0/mlflow/scorer/invoke from unfamiliar clients, particularly right after experiment creation, run creation and artifact uploads from the same source.
• List experiment artifact locations, including deleted experiments: python -c "import mlflow; from mlflow.entities import ViewType; [print(e.experiment_id, e.artifact_location) for e in mlflow.search_experiments(view_type=ViewType.ALL)]" with MLFLOW_TRACKING_URI set. Any location inside site-packages is a red flag.
• Look for uploaded files inside the installed package: find "$(python -c 'import mlflow, os; print(os.path.dirname(mlflow.__file__))')/genai/scorers" -name artifacts -type d.
• Review the container or host for unexpected processes, outbound connections and files.

Timeline#

• May 5, 2026 — MLflow 3.12.0 adds third-party scorer deserialization.
• Sep 16, 2026 — The fix (PR #25906) is merged.
• Oct 7, 2026 — MLflow 3.17.0 is released with the fix.
• Oct 27, 2026 — The advisory and CVE-2026-116692 are published.

Vulnerability records

• CVE-2026-116692 · MLflow is an open source AI engineering platform for agents, large language models, and machine learning models.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. MLflow — GHSA-26p8-2jq9-3vq9: Remote code execution via third-party scorer deserialization github.com
2. CVE record — CVE-2026-116692 cve.org
3. MLflow — PR #25906: Match third-party scorer modules exactly instead of by package prefix github.com
4. MLflow — Release v3.17.0 github.com
5. PyPI — mlflow release history pypi.org
6. GitHub Advisory Database — GHSA-26p8-2jq9-3vq9 github.com
7. Mend.io — WS-2026-0135: MLflow third-party scorer deserialization RCE mend.io