al-ice.ai

Root by Default, Read by Morning: MLflow 3.17.0 Fixes a 9.8 RCE and an Already-Exploited File Read

AI Vulnerabilities & CVEs by al-ice.ai Editorial

MLflow 3.17.0, released 27 October 2026, fixes two advisories that read like a before-and-after of the same bad assumption: CVE-2026-116692, a 9.8 CRITICAL unauthenticated remote-code-execution flaw in third-party scorer deserialization (GHSA-26p8-2jq9-3vq9, CWE-470/CWE-94), and CVE-2026-116690, a 7.5 HIGH arbitrary-file-read flaw in prompt model-version handling (GHSA-m65p-9j7q-6w33, CWE-22). The RCE reproduces as root on the official v3.14.0 image; the file read was caught being exploited in honeypots within a day of publication. Both advisories ship working proof-of-concept code. If you run an MLflow tracking server reachable from anywhere you wouldn’t run an open shell, upgrade now.

The RCE is the more instructive bug. Third-party scorer support arrived in MLflow 3.12.0, and the server accepts a request-controlled Python module path beneath one of four allowed package prefixes, imports it, and instantiates a request-controlled class synchronously. A package-name prefix is not a provenance boundary: an attacker uses MLflow’s own experiment, run, and artifact-upload endpoints to plant a module under an allowed path — create an experiment whose artifact location points at a writable scorer package, create a run, upload the Python file into the run’s artifact directory, submit a serialized scorer naming it — then triggers server-side import and construction through /ajax-api/3.0/mlflow/scorer/invoke. On the default no-auth server that is unauthenticated arbitrary Python execution with the server process’s privileges, and the reporter’s proof ran as uid 0 with the installed package tree writable. Affected: 3.12.0-rc.0 through 3.16.x; fixed in 3.17.0 via PR #25906. The bundled PoC is deliberately harmless — it writes a random marker beside the uploaded artifact and reads it back — which also means any competent attacker can swap in a non-harmless one.

The file read is the one already burning. The prompt-version branch added in 3.10.0 to fix CVE-2026-2614 validates the source only when it carries a URL scheme, so a schemeless value — ../../etc, a plain relative name, “.”, a percent-encoded path, a Windows drive-letter path — is stored unchanged as the model version’s artifact location, and the model-versions/get-artifact endpoint serves it with the server’s privileges. The tag check compounded it: it keyed on the presence of the mlflow.prompt.is_prompt tag rather than its value, so even a false value took the weaker branch. Basic-auth deployments are not spared — any authenticated user can create a registered model, so a low-privilege account can read the authentication database, including the admin password hash. Affected: 3.10.0 through 3.16.1; fixed in 3.17.0 via PR #25870, which accepts only MLflow’s own placeholder sources for prompt versions and requires the prompt tag to be true. Previdian’s honeypot network captured exploitation attempts within 24 hours of the 27 October publication, targeting files from /etc/passwd to SQLite tracking databases; the RCE has no confirmed in-the-wild exploitation so far. This continues MLflow’s rough year on unauthenticated surfaces — see the October trace-ID traversal with the fix still a pull request — and note the precedent: an earlier MLflow server-side-request-forgery flaw reportedly reached CISA’s KEV catalog in August.

Why defenders should take this seriously — and where to discount it

The serious part is the combination of defaults and disclosure: mlflow server runs without authentication by default, the official image runs as root, both advisories include working PoCs, and one flaw already has honeypot-confirmed exploitation inside a day. The file read is arguably the worse near-term risk — credential and tracking-database theft from an ML platform is the key material for everything downstream, including the model supply chain. The discount: the RCE chain, while unauthenticated, is multi-step and noisy (experiment creation, uploads, scorer invocation all hit the API), so decent request logging will show it; the “runs as root” detail is specific to the official container image rather than every deployment; and the KEV listing for the earlier SSRF flaw is reported via secondary coverage, not confirmed from the catalog in this briefing. Neither flaw is in KEV yet — but the file read has the exploitation evidence KEV is built on.

What it means for builders and defenders

  • Upgrade to 3.17.0 immediately on any network-reachable tracking server. No workarounds are documented for either flaw; the fix is the version bump. Then rotate anything the server process could read — especially the basic-auth database and any cloud credentials mounted into the container.
  • Stop running the tracking server as root and without auth. Both advisories’ worst outcomes flow from those two defaults. Put authentication in front, drop privileges, and restrict artifact-location writes to paths outside the Python package tree.
  • Hunt the RCE chain in API logs, not just the file read. Look for experiment creation with unusual artifact locations, Python file uploads to run-artifact paths, and POSTs to /ajax-api/3.0/mlflow/scorer/invoke from untrusted sources — plus get-artifact requests resolving outside the artifact root.
  • Treat MLflow servers as credential-bearing infrastructure. Tracking databases, prompt stores, and model artifacts are code-adjacent assets. Network-segment them like build systems: no direct internet exposure, egress filtering, and integrity monitoring on served artifacts.

Our verification was read-only. Both GitLab Advisory Database mirrors (pypi/mlflow CVE-2026-116692 and CVE-2026-116690, dated 27 October 2026) were read first-hand in full, including affected and fixed versions, weakness classes, CVSS vectors, the exploit chains, the root-reproduction detail, the tag-presence bypass, the basic-auth impact, and the GHSA/commit/PR/release references; the securityonline.info report of 28 October 2026 (Do Son) was read first-hand for the Previdian honeypot exploitation timing, the confirmed file targets, and the earlier-KEV context. The GitHub GHSA primaries and the MLflow v3.17.0 release notes are cited via the advisory references and were not fetched separately. No server was accessed, no PoC was run, no researcher or vendor was contacted, and all interpretation above is ours. Brave Search was used for discovery only.

Sources: