MLflow Third-Party Scorer Deserialization Enables Unauthenticated RCE on Default Servers (CVE-2026-116692)

What happened

A newly published GHSA advisory (GHSA-26p8-2jq9-3vq9, CVE-2026-116692, CVSS 9.8) details a remote code execution flaw in MLflow's third-party scorer feature, introduced in MLflow 3.12.0. According to the report, the server accepts a request-controlled Python module path under one of four allowed scorer package prefixes (ragas, deepeval, trulens, phoenix), imports that module, and instantiates a request-controlled class — without verifying that the module actually originated from a trusted source rather than from the caller.

The researcher's reported chain combines ordinary MLflow REST endpoints: create an experiment with an artifact location pointing inside a writable allowed scorer package, create a run (which allocates a run-scoped artifact directory under that package), upload a Python file as a run artifact, then submit a serialized scorer whose module path resolves to the uploaded file and trigger import/construction via /ajax-api/3.0/mlflow/scorer/invoke. On the stock, no-auth official MLflow v3.14.0 image — which the report says runs as uid 0 and has a writable package tree — this reportedly yields unauthenticated arbitrary code execution. A proof of concept was executed against both a local and a remote test instance, writing and retrieving a harmless marker file to demonstrate execution; no fixed release had been identified as of the report's July 2026 reproduction date.

Why it matters

MLflow is widely used as a tracking/model-registry server in ML pipelines, often deployed with authentication disabled in internal or dev/staging environments. The report states that in the default no-auth configuration, any network caller able to reach the tracking server can achieve code execution as the server process with no credentials and no user interaction — and that the official image runs that process as root, raising container-level impact. Per the advisory, even with MLflow's basic authentication enabled, the scorer-invocation endpoint reportedly lacks a resource-specific permission check, so any authenticated user able to create experiments/runs and upload artifacts may still reach the vulnerable import path. Given MLflow's footprint in ML infrastructure, this is a meaningful exposure for teams running tracking servers reachable from untrusted networks or shared by multiple principals.

What defenders should watch for now

• Inventory MLflow tracking server deployments and check version/exposure: is the server reachable from outside a trusted network, and is authentication enabled?
• Watch for anomalous experiment-creation calls where artifact_location points inside the MLflow installation's own package tree (e.g., paths containing site-packages/mlflow/genai/scorers/) rather than normal artifact storage.
• Monitor for unexpected .py file uploads to run-artifact directories, and for calls to the scorer-invoke endpoint (/ajax-api/3.0/mlflow/scorer/invoke) that reference unusual or run-scoped module paths.
• As a mitigation, consider restricting network access to the tracking server, enforcing authentication, running the server container as a non-root user with a read-only filesystem for the installed package tree, and disabling or closely reviewing the third-party scorer feature until a fix is available.

Developing intel

This is a freshly disclosed advisory and is not yet confirmed to have an official patched release; details may evolve as the vendor responds. Treat the specifics here as reported by the source, not independently verified by df00tech, and review the full technical writeup and proof-of-concept artifacts directly: GHSA-26p8-2jq9-3vq9.