MLflow at a glance
On October 27, 2026, MLflow published a critical advisory (CVSS 9.8): on default no-auth tracking servers, anyone who can reach the server can run Python code through the GenAI scorer endpoint. A second high-severity bug allows arbitrary file reads. Both are fixed in MLflow 3.17.0.
MLflow: status
- Affected
- MLflow 3.12.0 through 3.16.x tracking servers: unauthenticated code execution through third-party scorer deserialization (CVE-2026-116692) and SSRF through scorer settings (CVE-2026-115886)
- MLflow 3.10.0 through 3.16.1: arbitrary file read through prompt model version sources (CVE-2026-116690)
- MLflow 2.19.0 through 3.16.x with mlflow.crewai.autolog(): CrewAI provider API keys written into trace spans (CVE-2026-116691)
- CVE identifiers
- Status as of
- Discovered by
- GitHub user mskca (scorer RCE and file read), per the MLflow advisories
What changed with MLflow
On October 27, 2026, the MLflow project published GitHub advisories for its open-source tracking server, which many teams use to log experiments, prompts, traces and evaluations for LLM apps. The most serious, CVE-2026-116692, is rated critical with a CVSS score of 9.8. It affects MLflow 3.12.0 through 3.16.x and is fixed in 3.17.0, which was released on October 7.
The bug sits in the third-party scorer feature added in 3.12.0. The server imports a Python module named in the request as long as it starts with an allowed package prefix. The reporter showed that a caller can point a new experiment's artifact location inside one of those packages, upload a Python file as a run artifact, and then have the scorer endpoint import it. On the default server with no authentication, using the official image, that gives unauthenticated code execution; the advisory notes that image runs as root. With authentication on, the attacker needs an account that can create experiments and upload artifacts.
The same day MLflow disclosed CVE-2026-116690 (CVSS 7.5, versions 3.10.0 to 3.16.1): a prompt version with a schemeless local path as its source lets a caller read any file the server can read. On servers using basic-auth, a low-privilege user could read the authentication database, including the admin password hash. Two medium-severity issues are also fixed in 3.17.0: server-side request forgery through scorer settings (CVE-2026-115886), and mlflow.crewai.autolog() writing CrewAI provider API keys into trace spans (CVE-2026-116691).
How to fix it: MLflow
1. Update
Upgrade MLflow to 3.17.0 or later on every tracking server and client, then restart the server or redeploy its container.
github.com (opens in a new tab)2. Configuration
Do not expose an MLflow tracking server to untrusted networks without authentication; run it as a non-root user and keep its installed Python packages read-only, which the advisory says blocks this exploit chain.
github.com (opens in a new tab)3. Monitor
If you used mlflow.crewai.autolog(), search stored traces and any OTLP backend for provider API keys, delete them and rotate the keys.
github.com (opens in a new tab)4. Monitor
On basic-auth servers that ran 3.10.0 to 3.16.1, consider the authentication database exposed: change the admin password and review registered models for prompt versions with unusual local-path sources.
github.com (opens in a new tab)
Instruction for your AI agent
Search requirements files, lockfiles, Dockerfiles and compose or Kubernetes manifests for mlflow. If any pin or image uses a version below 3.17.0, propose upgrading to 3.17.0 or later. Flag any mlflow server command that listens on a public interface without an authentication layer, and any code that calls mlflow.crewai.autolog(); tell the user to check traces for leaked API keys. Ask before changing deployment settings or rotating keys.
Based on the official guidance linked below. Review it before giving it to an agent that can change your systems.
Advisories
Where to compare MLflow
Independent leaderboards and official resources for comparing this model yourself. Rankings change often; each site shows its own current data.
Why MLflow matters for businesses
If you track LLM experiments or agent traces in a self-hosted MLflow server, upgrade to 3.17.0, do not expose the tracking server to the internet without authentication in front of it, and run it as a non-root user with a read-only package directory. If you used CrewAI autologging, check your trace store and any OTLP backend for API keys and rotate any you find.
Sources for this story
- MLflow vulnerable to remote code execution on unauthenticated servers via third-party scorer deserialization (opens in a new tab)Official
MLflow on GitHub · github.com
- MLflow vulnerable to arbitrary file read on unauthenticated servers via prompt model version source (opens in a new tab)Official
MLflow on GitHub · github.com
- MLflow CrewAI autologging records LLM provider API keys in logged trace spans (opens in a new tab)Official
MLflow on GitHub · github.com
- MLflow v3.17.0 release (opens in a new tab)Official
MLflow on GitHub · github.com
Last verified: . IA Compa summarizes public announcements for business readers. We are not affiliated with the companies mentioned. Always confirm details, pricing, and availability with the official source.
- #security
- #cve
- #mlflow
- #llmops
- #remote-code-execution
- #self-hosting