CVE-2026-116692 is a remote-code-execution flaw in MLflow’s GenAI scorer feature, but its path to execution runs through ordinary tracking-server APIs. MLflow is an open-source AI engineering and MLOps platform used to track experiments and artifacts, evaluate models and agents, manage model versions, and operate AI applications. It is commonly run by data-science, ML platform, and AI application teams, whether locally, on premises, in containers, cloud deployments, or managed services.
The affected feature arrived in MLflow 3.12.0. The vendor advisory identifies affected mlflow releases as 3.12.0rc0 through versions before 3.17.0. This is not merely a risky model file: a request to the server can select Python code for the server itself to import.
A package allow-list became a write-and-import path
MLflow supports third-party scorers, Python components used to evaluate model or GenAI output. When deserializing a submitted scorer, vulnerable versions accepted a caller-controlled module path if it was one of four approved scorer packages or any dotted child beneath one. The server then imported that module, retrieved a caller-selected class, and instantiated it. Python executes a module’s top-level code during import, before any later class validation can provide protection.
An unauthenticated attacker needs an exposed MLflow server with authentication disabled and, crucially, a server process able to write under one of those allowed scorer-package paths. The documented chain creates an experiment with a local artifact location aimed at that writable package tree, creates a run, uploads a Python file as an artifact, and submits a serialized scorer pointing to that file. Invoking the scorer causes the server to import the attacker-placed module.
That yields arbitrary Python execution with the MLflow server process’s privileges. The controlled reproduction used the official 3.14.0 image, where the process ran as UID 0 and could write to the installed Python package tree. A read-only filesystem, or package directories the service cannot write, breaks this specific placement chain—but should be treated as defense in depth, not the fix.
Upgrade, then reduce the server’s reach
MLflow fixed the flaw in 3.17.0 by requiring an exact match to an approved module name rather than accepting descendants. Teams running any affected release should upgrade to 3.17.0 or later, identify tracking servers reachable by untrusted networks, and disable or tightly control unauthenticated access. They should also run MLflow as a non-root user, make application package paths non-writable, keep artifact storage separate from installed code, and review experiment and artifact API exposure.
A public proof of concept exists in the advisory: it uploads a harmless module whose constructor writes a random marker, then retrieves that marker through the artifact API to verify execution. No malicious exploitation in the wild or victim incident was confirmed as of October 30, 2026. CVE-2026-116692 was also absent from the CISA Known Exploited Vulnerabilities catalogue at the checked October 29 snapshot; that absence does not prove nobody has exploited it.
The same issue is also tracked as GHSA-26p8-2jq9-3vq9. For ML teams, the practical question is whether a tracking server can accept unauthenticated artifact and scorer requests—not whether it is marketed as a production model endpoint. Upgrade the server, constrain its filesystem and network exposure, and use SecAlerts to monitor the software your organisation actually runs for new vulnerabilities.
