MLflow CVE-2026-116692 Gives Unauthenticated RCE on No-Auth Servers

MLflow’s tracking server runs without authentication by default, according to one of the advisories (GHSA-m65p-9j7q-6w33). Three CVEs published on October 27 are a reminder of what that default costs.

What was published

All three records came from GitHub’s CNA on October 27, 2026, and NVD showed each as Awaiting Analysis when we checked. The scores below are GitHub’s, which NVD labels secondary.

• CVE-2026-116692 (CVSS 3.1 9.8, CWE-94; the GitHub advisory also lists CWE-470): unauthenticated remote code execution through third-party scorer deserialization. Affects MLflow 3.12.0rc0 up to 3.17.0.
• CVE-2026-116690 (CVSS 3.1 7.5, CWE-22): arbitrary file read on servers without authentication, through a model version tagged as a prompt. Affects 3.10.0 up to 3.17.0.
• CVE-2026-116691 (CVSS 3.1 6.5): mlflow.crewai.autolog() records LLM provider API keys from CrewAI agents in plain text in trace spans. Affects 2.19.0 up to 3.17.0.

The first advisory attaches proof-of-concept scripts and the second gives inline request sequences. We did not run either. Affected ranges come from the advisories, not from our own per-version testing.

How the code execution works

MLflow 3.12.0 added support for third-party scorers. When the server deserializes one, it takes a Python module path from the request, checks that it starts with one of four allowed package prefixes, imports it, and instantiates a class named in the request.

A prefix check is not a trust boundary. According to the advisory, an attacker can create an experiment whose artifact location points inside one of those allowed packages, create a run, upload a Python file as a run artifact, and then submit a scorer whose module path resolves to that file. The import runs the attacker’s constructor on the server.

The reporter says the chain worked on the official v3.14.0 container image, where the server ran as root and could write into its own Python package tree, and against a disposable cloud host they owned. Their proof is deliberately harmless: it writes a marker file. The invoke call returns an HTTP 500 afterwards, but only once the code has run.

Authentication changes less than you might hope. The advisory says the scorer endpoint is assigned a permission check that always returns true. An attacker on a basic-auth server still needs an account that can create experiments, runs and artifacts. A read-only filesystem, or a package directory the server user cannot write to, blocks this specific placement chain, per the same advisory.

The other two

The file-read bug follows an earlier fix. Per the advisory, the 3.10.0 patch for CVE-2026-2614 rejected file:// and absolute paths for prompt model versions, but let schemeless values like ../../etc through. The artifact endpoint then serves files from that location. On basic-auth servers, any user who can create a registered model could reach the authentication database, including password hashes.

The CrewAI one is quieter. The autolog code stringifies the agent’s fields, and the LLM object’s string form contains its API key. Anyone with read access to the trace backend or OTLP destination could see a live provider key. The reporter tested it with a fake credential on MLflow 3.16.0 and CrewAI 1.15.18.

What to do

Upgrade to MLflow 3.17.0 or later (PyPI also has 3.17.1 and 3.17.2, whose notes list no security items). The 3.17.0 release notes, which we opened, list a change matching scorer modules exactly instead of by prefix (#25906, GHSA-26p8-2jq9-3vq9) and another rejecting schemeless prompt sources (#25870). The notes also list a change sanitizing CrewAI LLM credentials from autolog spans (#25845, GHSA-j7qq-vr8c-xvw3).

One oddity: the code-execution advisory text says no fixed release was identified as of July 12, yet its metadata and the release notes point to 3.17.0, published October 7. That is 20 days before the CVEs went public. Our assessment is that the text was written before the fix and not updated.

If you cannot upgrade now, put the server behind authentication and a network allow-list (authentication narrows the exposure but does not remove it, since accounts that can create experiments, runs or registered models can still reach these bugs), run it as a non-root user with a read-only package directory, and rotate any CrewAI provider keys that passed through traces. We have not tested these mitigations, and the CrewAI rotation advice is ours.

For earlier MLflow trouble, see our coverage of CVE-2026-64849, an SSRF that was probed within hours of disclosure.

References

• GitHub — GHSA-26p8-2jq9-3vq9, MLflow RCE via third-party scorer deserialization (CVE-2026-116692)
• GitHub — GHSA-m65p-9j7q-6w33, MLflow arbitrary file read via prompt model version (CVE-2026-116690)
• GitHub — GHSA-j7qq-vr8c-xvw3, MLflow CrewAI autologging API key leak (CVE-2026-116691)
• NVD — CVE-2026-116692
• NVD — CVE-2026-116690
• NVD — CVE-2026-116691
• GitHub — MLflow v3.17.0 release
• CISA — Known Exploited Vulnerabilities catalog