CVE-2026-116692: MLflow RCE Vulnerability

Are You Affected?

CVE-2026-116692 affects MLflow installations from 3.12.0rc0 through versions before 3.17.0. The fixed release is MLflow 3.17.0. The vulnerability affects third-party scorer deserialization and module resolution, specifically the code path associated with mlflow/genai/scorers/base.py.

The highest-risk configuration combines an MLflow server exposed over the network, disabled authentication, and a server process that can write beneath a package path accepted by the third-party scorer allowlist. In that configuration, an attacker may be able to reach the scorer invocation workflow without credentials and trigger Python code execution in the MLflow server process.

Basic authentication changes the access requirement but does not remove the vulnerability. According to the supplied advisory details, an authenticated attacker needs a principal capable of creating an experiment and run and uploading artifacts. Managed services, vendor distributions, and container images should be checked independently because the supplied NVD record does not identify whether downstream packages have incorporated the upstream fix.

For broader vulnerability triage, compare this issue with other recent security advisories in our CVE-2026 vulnerability coverage.

Analyst’s Take: Upgrade first, then investigate exposure and access paths. The most urgent systems are unauthenticated, network-accessible deployments where the MLflow process can write beneath an allowed scorer package. Authentication and least privilege reduce exposure, but they do not remove the vulnerable code path.

The Fix, If You’re in a Hurry

Upgrade every affected MLflow installation to 3.17.0 or later. Confirm the running version after deployment rather than relying only on the package manifest, because MLflow may run in a container, virtual environment, managed platform, or separately maintained service image.

For a Python installation:

python -m pip install --upgrade "mlflow>=3.17.0"
python -c "import mlflow; print(mlflow.__version__)"

For a containerized deployment, update the image or build dependency to a release containing MLflow 3.17.0 or later, then recreate the workload. The exact image name and deployment command depend on the environment; updating a client package does not necessarily update the MLflow tracking server.

If an immediate upgrade is not possible, apply compensating controls:

• Require authentication.
• Restrict network access to MLflow tracking and serving interfaces.
• Limit access to /ajax-api/3.0/mlflow/scorer/invoke.
• Prevent the MLflow service account from writing to directories used by allowed scorer packages.
• Run MLflow under a dedicated least-privilege account.
• Isolate MLflow from sensitive credentials, cloud metadata services, production networks, and host administration interfaces.

A temporary reverse-proxy control might deny the scorer invocation endpoint except from approved administrative networks:

location = /ajax-api/3.0/mlflow/scorer/invoke {
    allow 10.20.0.0/16;
    deny all;
    proxy_pass http://mlflow_backend;
}

This reduces exposure but does not correct the unsafe module-loading behavior. It should not substitute for upgrading to MLflow 3.17.0 or later.

Technical Notes

After upgrading, verify the package and server image from the same runtime that launches MLflow:

python -m pip show mlflow
python -c 'import mlflow, sys; print(sys.executable); print(mlflow.__version__)'

Inspect effective filesystem permissions as well. The relevant question is whether the MLflow server process can create or modify Python modules beneath an allowed scorer package:

id
find /path/to/mlflow-runtime -path '*scorer*' -type d -exec ls -ld {} \;
find /path/to/mlflow-runtime -path '*scorer*' -type f -exec ls -l {} \;

Replace the example path with the actual runtime, site-packages, mounted artifact, or plugin location used by the deployment.

How This Vulnerability Works

The vulnerability is an insufficient allowlist check for third-party scorer modules. MLflow accepts descendants of THIRD_PARTY_SCORER_ALLOWED_MODULES rather than requiring the requested module to be an exact approved module.

That distinction is security-critical: if a permitted package hierarchy is writable by the server process, an attacker can place a Python module beneath it and then request that MLflow load the module.

The relevant invocation endpoint is:

/ajax-api/3.0/mlflow/scorer/invoke

The supplied technical description identifies this sequence:

1. An attacker writes a malicious Python module into a server-writable location beneath an allowed scorer package.
2. The attacker submits the module and class names through the scorer invocation API.
3. MLflow processes the request through Scorer.model_validate_json().
4. The scorer implementation imports the supplied module and constructs the selected class.
5. Code in that module executes with the privileges of the MLflow server process.

This is more than an ordinary artifact-upload issue. The security boundary fails when uploaded or attacker-controlled content becomes importable Python code in the server’s execution environment.

Potential impact includes:

• Modification of MLflow data.
• Theft of credentials available to the process.
• Access to cloud or internal services.
• Exposure or manipulation of model artifacts.
• Pivoting into connected infrastructure.

The exact impact depends on the service account, network placement, mounted secrets, and host controls.

Technical Notes

The vulnerable code path is associated with:

mlflow/genai/scorers/base.py

The request-controlled values of interest are the scorer module and class supplied to the scorer invocation workflow. Defenders should treat unexpected module and class combinations as high-value events, especially when they follow artifact uploads or experiment and run creation by a new principal.

A generic request pattern for reverse-proxy or API telemetry review is:

POST /ajax-api/3.0/mlflow/scorer/invoke

The endpoint alone is not proof of exploitation. It becomes more suspicious when the request is unauthenticated, originates from an untrusted network, or correlates with recent artifact uploads and creation of new experiments or runs.

Severity, Explained

The reported CVSS base score is 9.8, Critical. The supplied NVD response did not include the complete CVSS vector, so individual vector components should be verified against the official MLflow security advisory or a later NVD record update before publication or risk-scoring automation.

The operational severity is still clear. The attack is network-reachable through an MLflow API, and authentication may be absent in some deployments. Successful exploitation can result in arbitrary Python code execution under the MLflow server process.

MLflow commonly operates alongside model artifacts, experiment metadata, cloud credentials, data stores, and internal services, increasing the consequences of server compromise.

The practical risk is highest when all of the following conditions are present:

• The server runs an affected version from 3.12.0rc0 through before 3.17.0.
• The scorer invocation endpoint is network-accessible.
• Authentication is disabled or weakly controlled.
• The server process can write beneath an allowed scorer package.
• The service account has access to sensitive files, credentials, artifact stores, or internal networks.

A deployment that requires authentication and runs the service under a tightly restricted account is still affected, but its exploitability and blast radius are lower. These controls are defense in depth, not a replacement for the fixed release.

Is It Being Exploited?

No reliable primary-source confirmation of active exploitation was identified in the supplied research. CVE-2026-116692 is not listed in the CISA Known Exploited Vulnerabilities catalog as of 2026-10-27. There is therefore no CISA confirmation of exploitation in the wild or ransomware-campaign designation at the time of publication.

No verified public proof-of-concept repository was identified in the sources checked for this article. The absence of a public PoC or CISA KEV listing does not make the vulnerability low risk. The vulnerable flow involves a network-reachable API, attacker-influenced module and class selection, and Python code execution, making rapid exploitation plausible once technical details are understood.

Organizations should prioritize internet-facing and unauthenticated systems, search historical logs for suspicious scorer activity, and upgrade all affected installations. Treat unexplained successful requests to the scorer invocation endpoint, unexpected Python files in runtime directories, and anomalous child processes from MLflow as potential compromise indicators.