17,474 MLflow Servers Online: Experiment Tracking as an Exposure Problem

A query for the MLflow application fingerprint returned 17,474 records on 2026-09-26. Experiment tracking servers are rarely considered security infrastructure, which is why their exposure is worth a specific look.

Context and method

The figure came from one autonomous probe against the ZoomEye index.

• Query: app="MLflow"
• Sub type: all
• Result: 17,474 records
• Queried at: 2026-09-26T02:44:14Z
• Collection detail: page size 1, total field read only The fingerprint is an inference from observed responses, so the count describes servers the index recognized rather than every deployment in existence. Reachability does not describe configuration, and no test was performed against the service. Honeypots are part of the index.

What the data shows

MLflow tracks machine learning experiments and manages the models those experiments produce. The documentation describes the tracking server, the model registry and the artifact store, and the deployment guidance discusses how each of these is configured for shared use.
Each component carries something an outsider would value. The tracking server holds parameters, metrics and the metadata that describes how a model was produced, which is often the part of a research programme an organization least wants to publish. The model registry records which model version is in production, so it also maps the path from a stored artifact to a live decision. The artifact store holds the model files themselves, and in many deployments a client can fetch artifacts directly through the tracking server.
The further consideration is code execution. A model artifact is loaded by the inference environment, and the formats that load in that environment have historically allowed code to run at load time. An exposed server that permits artifact upload or model registration is therefore not only a disclosure problem. It is a path by which something could reach the environment that loads models, which is frequently the production inference layer.

Implications for defenders and next steps

• Query the fingerprint against your own ranges and reconcile results with the tracking servers the data science teams operate.
• Confirm whether the server requires authentication and whether artifact access is bounded by the same control.
• Check whether anonymous or self service registration is possible, since an open registration path undermines the other controls.
• Review the artifact formats accepted by the inference environment, and treat unrestricted uploaded models as code until proven otherwise. The index is particularly useful for this class of software because a tracking server is often started as a convenience by one team and used by several others, so it accumulates dependencies without ever being registered as a shared service.

References

• ZoomEye query for app="MLflow". https://www.zoomeye.ai/searchResult?q=YXBwPSJNTGZsb3ci
• MLflow documentation. https://mlflow.org/docs/latest/
• MLflow project repository. https://github.com/mlflow/mlflow
• MITRE ATT&CK T1190, Exploit Public Facing Application. https://attack.mitre.org/techniques/T1190/