A critical remote-code-execution vulnerability in MLflow gives unauthenticated attackers full control of servers running the open-source ML platform without authentication, according to a GitHub security advisory published on October 271.
Tracked as CVE-2026-116692 (GHSA-26p8-2jq9-3vq9), the flaw affects MLflow versions 3.12.0rc0 through versions before 3.17.0 and is patched in version 3.17.0.
MLflow 3.12.0 introduced registration and deserialization support for third-party scorers. During scorer deserialization, the server accepts a request-controlled Python module path beneath one of four allowed package prefixes, imports that module, obtains a request-controlled class, and instantiates it synchronously.
An attacker chains this behavior with MLflow's built-in experiment, run, and artifact-upload endpoints in five steps: create an experiment whose local artifact location points to a writable allowed scorer package; create a run so MLflow allocates an artifacts directory; upload a malicious Python module into that directory; submit a serialized third-party scorer whose module path resolves to the uploaded file; and trigger server-side import and class construction through the `/ajax-api/3.0/mlflow/scorer/invoke` endpoint.
On the default no-auth server using the official MLflow v3.14.0 image, the exploit produces unauthenticated arbitrary Python code execution with the privileges of the MLflow server process. The reproduced image runs that process as uid 0 and permits writes to its installed Python package tree, meaning an attacker gains root-level access.
The RCE is the most severe of three MLflow vulnerabilities surfaced on October 27. Vector Wire earlier covered CVE-2026-116690, a high-severity arbitrary file-read flaw affecting versions 3.10.0 through 3.16.1 on unauthenticated servers[2], and CVE-2026-116691, a medium-severity bug in which CrewAI autologging recorded LLM provider API keys in plaintext[1].
ANALYSIS The three disclosures share a common thread: each targets MLflow instances running without authentication, compounding the risk for teams that expose the platform's default configuration.
Operators running MLflow versions 3.12.0rc0 or later should upgrade to 3.17.0 immediately.