CVE-2026-116692: MLflow 3.17.0 fixes unauthenticated code execution through third-party scorers, an arbitrary file read through prompt versions, and CrewAI API keys leaking into traces
Three MLflow advisories were published on 27 October 2026, all fixed in MLflow 3.17.0. The worst lets anyone who can reach a default no-auth MLflow server upload a Python file as a run artifact and get the server to import and run it through the third-party scorer endpoint. A second lets a caller read any file the server can read by creating a prompt version with a relative source path. The third makes mlflow.crewai.autolog() write CrewAI LLM API keys into trace spans. Upgrade to 3.17.0.
What it is
CVE-2026-116692 (GHSA-26p8-2jq9-3vq9, code execution, MLflow 3.12.0rc0 to before 3.17.0): third-party scorer deserialization imports any module path that starts with one of four allowed package prefixes (for example mlflow.genai.scorers.trulens) and instantiates a caller-chosen class. A caller can create an experiment whose artifact location is inside that package directory, create a run, upload a .py file as a run artifact, and then call /ajax-api/3.0/mlflow/scorer/invoke so the server imports it. The advisory reproduced unauthenticated code execution on the official MLflow v3.14.0 image, which runs as root. With basic auth on, the scorer endpoint still skips a resource-level permission check.
CVE-2026-116690 (GHSA-m65p-9j7q-6w33, file read, MLflow 3.10.0 to 3.16.1): the CreateModelVersion handler only validated prompt-version sources that carried a URL scheme, so a schemeless path such as ../../etc was stored and later served by the model-versions get-artifact endpoint. On a no-auth server anyone can read files; on a basic-auth server any logged-in user can, including the auth database with the admin password hash.
CVE-2026-116691 (GHSA-j7qq-vr8c-xvw3, credential leak, MLflow 2.19.0 to before 3.17.0): mlflow.crewai.autolog() serialises the CrewAI Agent's fields, and the llm object's string form includes its api_key, so the LLM provider key ends up in span attributes and span inputs sent to the MLflow tracking server or your OTLP destination. The advisory verified this on MLflow 3.16.0 with CrewAI 1.15.18.
How to check
- Affected: mlflow (PyPI) before 3.17.0. The scorer RCE affects 3.12.0rc0 and later, the file read 3.10.0 and later, and the CrewAI key leak 2.19.0 and later.
- You are most exposed if an MLflow tracking server is reachable by people you don't fully trust, especially one started with plain mlflow server (no authentication), or if you used mlflow.crewai.autolog() with real provider keys.
How to fix
- Upgrade mlflow to 3.17.0 or later and restart the tracking server.
- Until then, don't expose the tracking server without authentication, and put it behind a network boundary only trusted users can reach.
- If you used mlflow.crewai.autolog(), assume the LLM provider keys in those traces are exposed: rotate them and delete or restrict the affected traces.
pip show mlflow | grep -i version
pip install -U 'mlflow>=3.17.0'