Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') Affecting mlflow package, versions [3.12.0rc0,3.17.0)
Threat Intelligence
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-PYTHON-MLFLOW-21756864
- published27 Oct 2026
- disclosed27 Oct 2026
- creditCarlos Munhos
Introduced: 27 Oct 2026
NewCVE-2026-116692 (opens in a new tab)How to fix?
Upgrade mlflow to version 3.17.0 or higher.
Overview
mlflow is a platform to streamline machine learning development, including tracking experiments, packaging code into reproducible runs, and sharing and deploying models.
Affected versions of this package are vulnerable to Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') via the model_validate method in mlflow/genai/scorers/base.py during third-party scorer deserialization. The module allow-list was previously matched by prefix (module_path.startswith(m + ".")), allowing an attacker to supply a module field whose dotted path begins with an allow-listed package name but resolves to an attacker-placed file - for example a run artifact uploaded under a file:// experiment root. When importlib.import_module is called with that path, the attacker-controlled module is executed in the server process before any class validation occurs, achieving remote code execution.
PoC
The attached reproduction is intentionally isolated:
- exact official MLflow v3.14.0 image pinned by manifest digest;
- Docker network disabled;
- MLflow bound to container loopback;
- no shell command or external callback;
- no external request;
- no host filesystem write;
- marker created beside the uploaded run artifact;
- marker retrieved through the run-artifact download endpoint; and
- disposable container removed after completion.
Run:
./run-official-image.sh
Expected output:
MLFLOW_VERSION=3.14.0
PACKAGE_DIR=/usr/local/lib/python3.10/site-packages/mlflow/genai/scorers/trulens
CREATE_EXPERIMENT_STATUS=200
CREATE_RUN_STATUS=200
UPLOAD_STATUS=200
INVOKE_STATUS=500
PROOF_DOWNLOAD_STATUS=200
PROOF_MATCH=1
RESULT=AFFECTED
The security-relevant result is:
PROOF_MATCH=1
RESULT=AFFECTED
This proves that the attacker-controlled constructor executed in the MLflow server process before the later scorer-processing failure.
Note: The PoC states it uses the official MLflow v3.14.0 Docker image pinned by manifest digest, with Docker networking disabled and MLflow bound to the container loopback.