MLflow tracking servers are built for collaboration. Data scientists create experiments, register models, store prompts and request artifacts from CI jobs, notebooks and cloud services. When the server also stores sensitive paths or credentials, the collaboration surface becomes a data-access surface.
On 28 October 2026, ZoomEye returned 18,020 assets for app="MLflow" with sub_type=all. The application fingerprint identifies matching deployments in the index. It does not show whether authentication is enabled, which model-registry permissions are active or whether a particular server is affected by CVE-2026-116690.
What the vulnerability asks defenders to check
MLflow versions 3.10.0 through 3.16.1 are affected by a path-validation flaw. A model version tagged as a prompt can use a schemeless local path as its source. The platform stores that value and later serves it through the model-version artifact endpoint with the permissions of the server process.
The default mlflow server is unauthenticated. In that mode, the advisory describes a remote unauthenticated file-read path. With basic authentication, a user who can create a registered model can still reach the same logic. The fixed release is 3.17.0.
A visible MLflow fingerprint is therefore a reason to inspect two things together: the version and the authentication and model-creation policy. A version upgrade without a review of who can create model versions may leave sensitive data reachable through a different account or path.
Map the server and its filesystem reach
Identify every tracking server, not just the UI users mention. Search DNS, reverse proxies, Kubernetes ingress rules, notebook configuration and CI environment variables. A server may be intentionally reachable to a research network and still hold cloud credentials with broad read access.
Record the process account, mounted secrets, artifact store permissions and the authentication mode. If the server reads from an object store, ask whether the credentials can read other buckets. If it runs in Kubernetes, check the service account and mounted volumes. The vulnerability provides a file-read primitive, so the impact depends on what the process can see.
Update to MLflow 3.17.0 and rebuild the image or environment. Verify the running version from inside the process, then test a harmless schemeless model-version source and confirm that the endpoint rejects it. A static dependency report does not prove that the serving process was restarted with the new package.
Review registry and artifact access
Search model-version creation records for unusual prompt tags or local-looking source values. Then correlate those records with get-artifact requests, authentication identity and access time. Export the relevant audit logs before rotating credentials or deleting test objects.
If the server was unauthenticated, review whether the network policy allowed external access and whether any unfamiliar model versions appeared. If basic authentication was configured, identify who could create models and whether a low-privilege account could have been used. Rotate credentials that the process could read and check downstream cloud logs for use.
Do not describe an indexed MLflow server as compromised. The count tells the team where to look. Incident evidence comes from the server's own logs, version and filesystem access records.
Make model provenance narrow
A model registry should accept trusted artifact references from a controlled source. Validate the source type, enforce authorization on the underlying model and artifact, and log the caller and resolved location. Run the server with a dedicated account that can read only the artifacts and configuration it needs.
Put the tracking API behind an authenticated gateway even if a team considers the network internal. The 18,020 fingerprint matches show that MLflow is common enough to merit its own inventory category. Security teams should know who runs each instance, what it can read and which users can register a model before they need to investigate a file-read report.