An experiment tracker often holds more than model metrics. It can contain environment details, artifact paths, prompt templates and the service accounts used to access cloud storage. CVE-2026-116690 shows how a validation gap in MLflow's prompt model-version path can turn that repository into a file-read service.
MLflow versions 3.10.0 through 3.16.1 are affected. The fixed release is 3.17.0. The advisory explains that _create_model_version() validates paths only when the source has a URL scheme. A schemeless value such as a relative path or a Windows drive-letter path can therefore be stored as the model version's artifact location. The model-versions/get-artifact endpoint then serves files with the permissions of the MLflow server process.
Default authentication changes the attack surface
The mlflow server default runs without authentication. In that configuration, the advisory describes remote unauthenticated access to the file-read path. A server using basic authentication is not necessarily safe: the advisory says an authenticated user who can create a registered model can exploit the same flaw. That can expose the authentication database and potentially its password hashes to a low-privilege account.
This distinction matters during triage. An internal MLflow instance may still deserve urgent treatment because a compromised developer account or an over-permissive service token can create the required object.
Locate every tracking server
Search application inventories, reverse proxies, Kubernetes ingresses and cloud load balancers for MLflow tracking servers, not only the MLflow UI. A server may be reachable from notebooks and CI runners without being advertised to end users. Record the running version, authentication mode, model-creation permissions and the filesystem identity of the process.
Update MLflow to 3.17.0 and rebuild images or virtual environments that bundle it. Confirm that the running process reports the expected package version and that the endpoint rejects a controlled schemeless source. Do not test with a sensitive file; use a harmless path that you create for verification.
If the service cannot be updated immediately, restrict access to trusted users and networks. Enable authentication and tighten model-creation permissions, but do not present those steps as a complete substitute for the fixed validation logic.
Review what the server could read
The MLflow process may have access to its own configuration, authentication database, cloud credentials, mounted secrets and artifact stores. Determine which files were readable from its account. Then review model-version creation events and artifact requests around the exposure window, including the caller identity and source values.
A successful file read may leave only a normal-looking artifact request. Export audit logs and preserve the server's configuration before rotating credentials. Compare any get-artifact request for an unusual source with model-version creation records and the user's normal activity.
If the process could read cloud credentials, rotate those credentials and inspect the corresponding cloud audit logs. If it could read the authentication database, treat stored password hashes as exposed and review administrator sessions and password reset activity.
Make model provenance a closed path
The service should accept artifact references from a defined registry or MLflow-owned placeholder, not arbitrary local paths. Validate the source type before storing it, resolve the final storage location, enforce authorization at the object level and log the source value with the caller. Run the server with the least filesystem access it needs.
These rules apply to every model registry and prompt store. A model version is a supply-chain object. Its provenance field should describe a constrained location that the platform controls, not a path that lets the server browse its own host.