Rack of server equipment with indicator lights in a dark data room

MLflow’s Critical RCE Flaw: A Patching Playbook for ML Platform Teams

por

Rodrigo Gardin
em

| From

If your team runs a self-hosted MLflow tracking server, the MLflow RCE tracked as CVE-2026-116692 deserves a slot in this week’s patch window. The GitHub advisory rates it Critical, CVSS 9.8, and it affects every release from 3.12.0rc0 up to, but not including, 3.17.0. A second critical advisory landed on Oct 26 for Google’s MCP Toolbox for Databases. Both flaws come from the same habit: tooling that lets a caller pick the module or path it acts on.

Here is a practical order of operations for ML platform teams, including nearshore and outsourced ones that run these servers for someone else.

What the MLflow flaw actually allows

According to the advisory, the scorer deserialization code imports a module chosen by the request, as long as it sits under an allowed package prefix. An attacker can use MLflow’s own experiment, run and artifact endpoints to upload a Python module into a scorer package directory, then trigger the import. The reporter’s proof of concept was harmless, but it confirmed that code ran inside the server process.

Exposure depends on setup. The Ostorlab analysis notes that authentication is off by default and that mlflow server binds to 127.0.0.1 unless you set another --host. The server process also has to be able to write inside an installed scorer package. Teams that put the tracking server behind a shared ingress with no auth are the obvious targets.

One assumption is worth killing early: turning on basic auth does not close the hole. Ostorlab points out that any authenticated user who can create experiments, runs and artifacts can still reach the scorer invoke endpoint, which has no resource-specific permission check.

Step 1: Find every MLflow server you own

Inventory comes before patching. Look beyond the production tracking server: notebooks, staging clusters, and the container images that data science teams built months ago all count. For each instance, record three things.

  • The installed MLflow version (anything from 3.12.0rc0 to 3.16.x is in range)
  • Whether auth is enabled and which network paths can reach the server
  • Whether the server user can write to the installed mlflow package directories

If you are a vendor team running this for a client, send that table to the client’s security contact now. It is cheaper than explaining later why nobody knew the server existed.

Step 2: Upgrade to 3.17.2, not just 3.17.0

The fix first shipped in 3.17.0. According to the MLflow releases page, 3.17.0 went out on Oct 7, 3.17.1 on Oct 13 and 3.17.2 on Oct 21. The 3.17.0 changelog lists a change to confine custom scorer code execution to the job executor. Per Ostorlab, the exact-match fix is commit a732443e, which replaces the prefix check, validates metric_name and requires the class to be a Scorer subclass before it is instantiated.

Aim for 3.17.2 because of a separate flaw. CVE-2026-53995 is a path traversal in the FileStore backend, rated High (CVSS v4 8.8), affecting 3.17.1 and earlier and patched in 3.17.2. FileStore stopped being the default in 3.7.0, but deployments that still use it are exposed.

Plan the upgrade rather than just bumping a tag. The releases page states that 3.17.0 requires a database upgrade for SQL-backed servers and that mixed-version rolling upgrades are not supported. That means a short maintenance window, a database backup and a single cutover, not a gradual rollout across replicas.

Step 3: If you cannot patch today

Mitigations reduce exposure but do not remove the bug. Ostorlab lists the realistic options:

  • Restrict network access with loopback binding, a VPN, an authenticating ingress or an IP allowlist
  • Run the server on a read-only filesystem, or make the scorer package directories unwritable by the server user, which breaks the file placement step
  • Enable basic auth, knowing it only narrows the set of people who can attack

Step 4: Hunt for signs of compromise

The advisory had been public since Oct 9, with a proof of concept attached, before it reached the GitHub Advisory Database on Oct 27. Ostorlab reports no known in-the-wild exploitation and no CISA KEV listing as of Oct 28, but that is not a reason to skip the check. Its suggested indicators:

  • Recently modified .py files inside installed scorer packages
  • Experiments whose artifact location is a file:// path under site-packages/mlflow/genai/scorers/
  • Scorer invoke requests with .artifacts. in the module path, and uploads of .py files

A clean log review is weak evidence, since code running as the server can delete traces. If you find any of these, treat the host as compromised, rotate every credential it could read, and rebuild from a clean 3.17.2 image.

The same pattern in Google’s MCP Toolbox

If you also run Google’s MCP Toolbox, check it in the same pass. CVE-2026-93328, published Oct 26, is a path traversal and missing authorization flaw in the cloud-storage source of Google’s MCP Toolbox for Databases. Per the GitHub advisory, an unauthenticated remote attacker can exfiltrate host files to external Google Cloud Storage buckets and overwrite local files through crafted tool invocation parameters. It scores 9.3 on CVSS 4.0, and the description covers versions 1.2.0 through 1.4.0.

The advisory is still unreviewed and lists the patched version as unknown, so check the source. The fix pull request adds allow-lists for buckets and local paths and checks storage operations against them, and the release notes tie it to version 1.5.0. A later release, 1.10.0, resolves symlinks when enforcing local path boundaries, according to the project releases page. The practical move is to upgrade to the current release and configure the allow-lists instead of leaving the source unrestricted.

What to ask your vendors

Both flaws were fixed upstream before the public advisories landed, which is the normal shape of this problem: the patch exists and the exposed instance is the one nobody updated. If an outsourced team operates your ML platform, put three questions in the next status call:

  1. Which MLflow and MCP Toolbox versions are running, and where?
  2. How long from an upstream fix to production, and who signs off?
  3. Which of these servers are reachable from outside a private network?

Teams that can answer those in a day were ready for this advisory. If yours cannot, that gap is the real finding. Want help building an inventory and patch process for your ML stack? Talk to the engineers at Luby.