A CVSS 9.8 in MLflow Lets One Uploaded Python File Take Over the Server Running Your AI Evaluations

MLflow, the open source platform that sits at the center of a large share of the world's machine learning and LLM evaluation pipelines, has patched a critical remote code execution vulnerability that could hand attackers full control of the server running it. The flaw, CVE-2026-116692, carries a CVSS 3.1 score of 9.8 and affects every release from 3.12.0rc0 up to but not including 3.17.0, where the fix landed.

The bug lives in third-party scorer deserialization in mlflow/genai/scorers/base.py. MLflow maintains an allowlist of permitted scorer modules, but the check accepts any descendant of an allowed package rather than requiring an exact match. An attacker can use MLflow's artifact upload endpoints to place a malicious Python module inside a writable allowed package, then submit that module and class through the /ajax-api/3.0/mlflow/scorer/invoke endpoint. The server's Scorer.model_validate_json() imports the module and constructs the class before any trace processing happens — and the attacker's code runs with the privileges of the MLflow server process.

What makes the exposure severe is how permissive default deployments are. On servers with authentication disabled, the attack requires no credentials at all. Even with basic authentication enabled, the invoke endpoint is guarded only by a validation function that returns True without checking experiment-level or scorer-level permissions, so any user who can create an experiment and upload a run artifact can escalate to full server-side code execution.

The official container image makes it worse. Security research published this week against the ghcr.io/mlflow/mlflow:v3.14.0 image showed the server runs as root with a writable system site-packages directory, meaning a successful exploit yields root-level control of the entire container. In the documented test, the malicious payload executed as uid 0, wrote a verification marker file, and the researcher confirmed execution through a subsequent artifact download despite the API returning a 500 response.

The blast radius extends well beyond MLflow's own data. Tracking servers routinely hold proprietary model weights, training datasets, evaluation traces, and backend database credentials. They also frequently carry cloud provider credentials — AWS IAM roles, GCS service account keys, Azure storage tokens — and third-party LLM API keys, including OpenAI and Anthropic credentials configured for AI gateway and evaluation features. Compromise the evaluation server, and you inherit the keys to the production stack it measures.

The fix is in MLflow 3.17.0, which enforces exact allowlist matching, with the patch tracked in pull request #25906. Operators who cannot upgrade immediately can break the attack chain by making site-packages and everything on sys.path read-only to the server process, running containers as an unprivileged user with a read-only root filesystem, and configuring --serve-artifacts against remote object storage such as S3, GCS, or Azure Blob instead of local file paths. Unauthenticated MLflow servers should never face an untrusted network.

As of October 27 the vulnerability was not listed in CISA's Known Exploited Vulnerabilities catalog and no public proof-of-concept repository had been identified. But the pattern is becoming familiar: the tooling built to evaluate AI systems is itself becoming attack surface, and an unpatched evaluation server now shares a threat model with the production models it watches.