Advisory · CVE-2026-116692
MLflow scorer deserialization can execute code on the tracking server
MLflow 3.12.0 release candidates through before 3.17.0 accept request-selected third-party scorer modules without requiring an exact allowed module, letting a caller place a Python module under a writable allowed package and have the server import and construct it through the scorer invoke endpoint. Authentication-disabled deployments need no credentials. CVSS 3.1 9.8.
- Vendor
- MLflow
- Product
- MLflow
- Identifier / CWE
- CVE-2026-116692
CWE-94, CWE-470 - Action timing
- Immediate
Explain it like I’m five
MLflow lets callers name a scoring plugin to load, and it trusts sub-modules of allowed packages instead of checking the exact name. An attacker can smuggle their own Python module under an allowed package's umbrella and have the server load and run it.
- 01Module planted
The attacker uses MLflow artifact endpoints to place a Python module beneath a writable allowed scorer package.
- 02Scorer invoked
The attacker submits the module and class through the /ajax-api/3.0/mlflow/scorer/invoke endpoint.
- 03Server imports it
Scorer validation imports the module and constructs the class before trace processing.
- 04Code executes
The attacker's code runs in the MLflow server process; on authentication-disabled deployments this needs no credentials at all.
What happened
The MLflow project published CVE-2026-116692 on October 27, 2026, rated critical at CVSS 3.1 9.8 in its GitHub advisory: from 3.12.0rc0 until 3.17.0, third-party scorer deserialization in mlflow/genai/scorers/base.py accepts request-selected descendants of the allowed modules list rather than requiring an exact allowed module. A caller can use MLflow artifact endpoints to place a Python module beneath a writable allowed package and submit its module and class through the scorer invoke endpoint, and the server imports the module and constructs the class before trace processing (CWE-94, CWE-470).
Per the advisory, authentication-disabled deployments permit this code execution without credentials, while basic-auth deployments require a principal capable of creating an experiment and run and uploading artifacts; in either configuration the allowed scorer package must be writable by the server process. The issue is fixed in MLflow 3.17.0.
What to do
- Inventory MLflow tracking servers, including research, development, and individually managed cloud deployments, and note versions.
- Upgrade affected servers to MLflow 3.17.0 or later.
- Until upgraded, disable or network-restrict the scorer invoke endpoint and artifact upload paths, and require authentication on every MLflow deployment.
- Review experiment and run creation, artifact uploads, and scorer invocations for modules or classes you do not recognize, especially under allowed scorer packages.
- Treat the MLflow host as exposed if suspicious scorer activity is found: rotate cloud credentials, service tokens, and data-store secrets reachable from the server.
- Verify the deployed version after updating and confirm scorer packages are not writable by the server process.
Management note
MLflow servers concentrate model artifacts, experiment data, and cloud credentials, and this flaw turns a plugin mechanism into remote code execution. The authentication-disabled case should end the debate about internal-only ML tooling: patch it, authenticate it, and keep it off shared networks.