MLflow CVE-2026-116692 (CVSS 9.8) Lets Callers Run Code on No-Login Tracking Servers: Update to 3.17

TL;DR: If your team runs its own MLflow server to track experiments, models or LLM evaluations, check the version. MLflow 3.12.0 through 3.16.x has a critical flaw, CVE-2026-116692 (CVSS 9.8): on a server started without a login, which is how mlflow server runs by default, anyone who can reach its web API may be able to run their own Python code on it. The fix shipped in MLflow 3.17.0 on October 7; what’s new is the public advisory, added to GitHub’s Advisory Database on October 27 (UTC), so dependency scanners will start flagging old servers now. Update to 3.17.0 or later, and don’t leave an MLflow server open to the internet without a login. No attacks have been reported.

What happened

MLflow’s maintainers published security advisory GHSA-26p8-2jq9-3vq9 on the project’s GitHub repository on October 9, 2026 (UTC). GitHub added it to its global Advisory Database on October 27 at 21:26 UTC (5:26 a.m. October 28 in Manila), and the CVE record, CVE-2026-116692, went public the same day. It is rated 9.8 (critical) under CVSS 3.1. Affected versions run from 3.12.0rc0 up to, but not including, 3.17.0, which went to PyPI on October 7. The latest release at our check is 3.17.2.

The flaw sits in MLflow’s scorer feature, which grades model and LLM output. Since 3.12.0, the server can load “third-party” scorer code from four allowed Python package paths. The advisory says the server trusted any module path supplied in the request as long as it started with one of those prefixes. MLflow’s normal API also lets a caller create an experiment, choose where its files are stored and upload files to a run. Combined, a caller can upload a Python file into a folder the scorer loader trusts and then ask the server to import it.

The reporter demonstrated this on MLflow’s official v3.14.0 Docker image. In the advisory’s words, on “the default no-auth server using the official MLflow v3.14.0 image, this produces unauthenticated arbitrary Python code execution with the privileges of the MLflow server process.” That image runs the server as root. The advisory notes the attack also needs the server process to be able to write inside MLflow’s installed package folder, which is true in the official image and “may hold in virtual environments installed and run by the same operating-system user.”

Turning on MLflow’s basic authentication means a login is required. But the advisory says the scorer endpoint doesn’t check permissions on the specific experiment, so a signed-in user who can create runs and upload files may still be able to do the same.

GitHub’s Advisory Database added a second MLflow advisory the same day, GHSA-m65p-9j7q-6w33 (CVE-2026-116690, CVSS 7.5), which MLflow had posted on its repository on October 13: an arbitrary file read in versions 3.10.0 through 3.16.1, also fixed in 3.17.0. On servers with basic auth, the advisory says any signed-in user can use it to read the authentication database, “including the admin password hash.”

Neither flaw is in CISA’s Known Exploited Vulnerabilities catalog at our check, and neither MLflow nor GitHub reports attacks.

Why it matters

MLflow servers usually sit next to valuable things: cloud storage keys for artifacts, database connections, API keys for model providers and sometimes training data. Code running inside the server can generally reach all of it, and in the official image it runs as root.

The fix is three weeks old, so teams that update regularly are likely covered. The risk is the server someone spun up once on a cloud VM, opened to the team on port 5000 and never touched again. It’s the same lesson as the critical flaws in Agno and the OpenHands SDK and Google’s MCP Toolbox: AI tooling needs the same patching and network rules as any web app. Our Security hub tracks the rest.

What to do now

1. Find every MLflow server you run. Check VMs, containers and notebooks. Run mlflow --version or pip show mlflow, or check the image tag.
2. Update to 3.17.0 or later (3.17.2 is current) and restart the server. If you use the official Docker image, pull a fixed tag and redeploy. Our advice: update lock files and rebuild custom images so an old version doesn’t creep back.
3. Close the open port. Our advice: if the server’s port is reachable from the internet, restrict it to known IPs with a firewall or security-group rule, or reach the server over an SSH tunnel or VPN.
4. Turn on authentication for any server more than one person uses. Our advice: treat it as a second layer, since a login alone doesn’t fully close this flaw on old versions.
5. If the server was exposed and unpatched, assume the worst. Our advice: rotate any credentials it could read, such as cloud storage keys, database passwords and model-provider API keys.
6. Look for leftovers. Our advice: check your artifact storage for unexpected .py files, especially in folders named like MLflow’s own scorer packages, and for experiments or runs you don’t recognize.

Updates

• Oct 28, 2026, 10:45 a.m. Manila: First published. Neither CVE is in CISA’s KEV catalog and no exploitation is reported at our check.

Sources & method

Sources

• GitHub Advisory Database, GHSA-26p8-2jq9-3vq9 / CVE-2026-116692 (October 27, 2026)
• MLflow’s security advisory GHSA-26p8-2jq9-3vq9 in the mlflow/mlflow repository
• GitHub Advisory Database, GHSA-m65p-9j7q-6w33 / CVE-2026-116690 (October 27, 2026)
• MLflow release v3.17.0 on GitHub
• MLflow release history on PyPI (3.17.0 on October 7, 3.17.2 on October 21)
• CVE.org record CVE-2026-116692
• CISA Known Exploited Vulnerabilities catalog (neither CVE listed at our check)

Method. Last checked October 28, 2026, at 10:05 a.m. Manila time (02:05 UTC). The flaw description, affected and fixed versions, quotes, CVSS scores and the basic-auth caveats come from the two GitHub advisories; publication times come from GitHub’s advisory and repository-advisory data and the CVE records; release dates come from PyPI. We checked CISA’s Known Exploited Vulnerabilities catalog. Steps labelled “our advice” are our own. No affiliate links on this page. How we work.