Overview

A critical path traversal vulnerability, CVE-2023-1177, was discovered in MLflow, the widely used open-source platform for managing machine learning lifecycles. The flaw allows any unauthenticated user to read arbitrary files from the server's filesystem by exploiting insufficient path validation in MLflow's model artifact handling. The vulnerability stems from insufficient sanitization of the source parameter when creating model versions, allowing an attacker to register a model pointing to a local filesystem path and then retrieve arbitrary files through the artifact retrieval endpoint. A public proof-of-concept exploit was released shortly after disclosure. It has been assigned a CVSS v3.1 score of 9.8 (Critical).

Under specific additional conditions, such as having write access to the server or pointing the model source at a network-accessible malicious artifact store, this file read primitive can be escalated to remote code execution. That escalation is not automatic and requires prerequisites beyond the base vulnerability.

Affected Versions

The following MLflow versions are vulnerable:

• MLflow prior to 2.2.1

MLflow 2.2.1 introduced the initial patch addressing this vulnerability. However, a bypass of that fix was subsequently discovered, and MLflow 2.3.0 contains the more complete remediation. Organizations should upgrade to 2.3.0 or later. At the time of disclosure, a significant number of MLflow tracking servers were found to be publicly exposed on the internet with no authentication enforced, a configuration that is common in internal data science environments where MLflow is treated as a trusted internal tool.

Why This Vulnerability Matters

MLflow is one of the most widely deployed platforms in the machine learning ecosystem, used by data science teams across financial services, healthcare, technology, and research institutions. It manages experiments, model versioning, and artifact storage, sitting at the core of ML pipelines that often have access to sensitive training data, credentials, and cloud infrastructure.

CVE-2023-1177 is particularly dangerous because:

• It requires no authentication in the default MLflow deployment, which ships with auth disabled
• It abuses a legitimate platform feature (model artifact registration) rather than a memory corruption or injection bug
• It allows arbitrary file reads from the server filesystem, including /etc/passwd, SSH keys, cloud credential files, and environment variables
• Under additional conditions, it can escalate to remote code execution via MLflow's support for loading model artifacts from arbitrary URI schemes, including file:// paths pointing to malicious Python model code
• Exploitation is straightforward and fully scriptable via the MLflow REST API

Any MLflow deployment running a vulnerable version with network exposure should be treated as at serious risk if untrusted users had any degree of API access.

What Is MLflow and the Model Registry Feature

MLflow is an open-source platform designed to manage the full machine learning lifecycle, including experiment tracking, model packaging, and deployment. It is commonly deployed as an internal tracking server where data scientists log runs, compare metrics, and register trained models for promotion to production.

The Model Registry is a core MLflow feature that provides a centralized store for managing model versions. When a user registers a model version, they supply a source parameter that tells MLflow where the model artifacts are located. This is typically an S3 path, a GCS URI, or a local path on the MLflow server. MLflow uses this source to retrieve and serve the model artifacts when requested.

The artifact serving endpoint /model-versions/get-artifact allows users to download files from a registered model's source path. This endpoint accepts a path parameter specifying which file within the source to retrieve. The combination of an unsanitized source URI and an unsanitized path parameter creates the traversal and file read primitive at the heart of this vulnerability.

Root Cause of CVE-2023-1177

The vulnerability is a path traversal issue (CWE-22), not an SSRF or Local File Inclusion in the traditional sense. The official classification describes it as improper neutralization of path traversal sequences in user-supplied input used to construct filesystem paths.

MLflow's model version creation endpoint (/ajax-api/2.0/mlflow/model-versions/create) accepts a source parameter without sufficiently validating the URI scheme or resolving the path against a permitted base directory. This allows an attacker to supply file:///etc/ or any other local filesystem path as a model source, effectively registering a model that points anywhere on the server.

The artifact retrieval endpoint (/model-versions/get-artifact) then accepts a path parameter and constructs the final file path by joining the registered source with the supplied path. Because neither component is validated against a safe root, the server reads and returns the file at the constructed path directly.

The root cause is a classic path traversal pattern: user-controlled input is used to construct a resource path without canonicalization or allowlist enforcement. Escalation to remote code execution is possible but conditional: it requires either write access to a path on the server, or the ability to point the source at a network-accessible malicious artifact store serving a crafted Python-based MLflow model.

How the Exploit Works

The exploit follows a straightforward and fully API-driven chain.

Step 1: Reach the API. In default MLflow deployments, no authentication is required. The attacker only needs network access to the MLflow tracking server, typically running on port 5000.

Step 2: Register a model with a malicious source. The attacker calls the model creation endpoint to register a named model, then calls the model version creation endpoint supplying source: "file:///etc/". MLflow accepts this without complaint and stores the path as the artifact source for that model version.

POST /ajax-api/2.0/mlflow/registered-models/create
POST /ajax-api/2.0/mlflow/model-versions/create
  { "name": "<model_name>", "source": "file:///etc/" }

Step 3: Retrieve the target file. The attacker calls the artifact retrieval endpoint, specifying the registered model name, version, and a path value corresponding to the target file:

GET /model-versions/get-artifact?name=<model_name>&version=1&path=passwd

Step 4: Server returns file contents. MLflow joins file:///etc/ with passwd, reads /etc/passwd from the local filesystem, and returns it in the HTTP response body.

Step 5: Escalate to RCE (conditional). For remote code execution, the attacker must either have write access to a path on the server and register that path as the source, or point the source at a network-accessible location they control that serves a malicious MLflow model containing a crafted MLmodel file and a Python flavor that executes arbitrary code when loaded. This step requires prerequisites not present in all deployments.

Why Unauthenticated Access Is the Default

A critical aggravating factor for CVE-2023-1177 is that MLflow's tracking server ships with authentication disabled by default. This design reflects MLflow's origin as an internal research tool, built for use within trusted network boundaries rather than public-facing deployment.

In practice, however, MLflow instances are routinely:

• Deployed on cloud VMs with permissive security group rules
• Exposed behind corporate VPNs accessible to broad internal populations
• Run on developer workstations with port-forwarding or ngrok tunnels for collaboration
• Deployed in Kubernetes clusters with overly broad ingress rules

The combination of no default authentication and a critical path traversal vulnerability means that a significant portion of real-world MLflow deployments were directly exploitable the moment a public PoC was available.

Impact

Successful exploitation of CVE-2023-1177 allows an attacker to:

• Read arbitrary files from the server filesystem, including /etc/passwd, /etc/shadow, SSH private keys, .env files, cloud provider credential files (~/.aws/credentials, ~/.config/gcloud), and application secrets
• Exfiltrate MLflow internals such as experiment data, model metadata, and artifact storage credentials embedded in the MLflow configuration
• Achieve remote code execution under certain additional conditions by registering a malicious model artifact and triggering its load, executing commands with the privileges of the MLflow server process
• Pivot to connected infrastructure, as MLflow servers frequently have IAM roles, service account tokens, or database credentials that provide access far beyond the MLflow instance itself

The base vulnerability requires no user interaction and is fully exploitable via scripted HTTP requests. RCE requires additional attacker-controlled conditions.

Remediation and Mitigation

Official Fix

The vulnerability was initially patched in MLflow 2.2.1. However, a bypass of that fix was discovered, and a more complete remediation was released in MLflow 2.3.0. Organizations should upgrade to MLflow 2.3.0 or later.

Recommended Actions

• Upgrade all MLflow deployments to 2.3.0 or later
• Audit existing model versions in the registry for suspicious source URIs (particularly file:// paths)
• Review MLflow server access logs for anomalous calls to /model-versions/get-artifact and /ajax-api/2.0/mlflow/model-versions/create
• Enable MLflow's built-in authentication (introduced in later versions) or place the tracking server behind an authenticated reverse proxy
• Restrict network access to the MLflow tracking server to known-good CIDR ranges

Temporary Mitigation

If immediate patching is not possible, block external access to the MLflow API entirely using network-level controls. Place the server behind a reverse proxy that requires strong authentication before any request reaches MLflow. Audit and remove any file://-scheme entries already present in the model registry. These are not substitutes for patching but significantly reduce the exploitable attack surface.

Final Thoughts

CVE-2023-1177 is a sharp reminder that developer-tooling platforms accumulate trust and access far beyond what their security posture reflects. MLflow was built by and for data scientists, not adversaries, and that orientation shows in the default configuration. No authentication, no URI scheme validation, and direct filesystem access via a documented API feature is a combination that turns any network exposure into a serious incident.

The vulnerability also highlights a pattern common in the ML tooling ecosystem: features designed for flexibility in trusted environments (registering models from arbitrary sources, loading Python artifacts dynamically) become critical attack primitives when the trust boundary dissolves. The same capability that lets a researcher quickly register a local model for tracking becomes an unauthenticated path traversal endpoint when the server faces an untrusted network.

For pentesters and red teamers, MLflow tracking servers are worth enumerating in any engagement touching data science infrastructure. Default port 5000, no auth, and a public PoC make this a reliable path to initial access or lateral movement in organizations with active ML workflows.

If you are running MLflow prior to 2.3.0 with any network exposure, patch immediately and audit your model registry for signs of abuse.

References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-1177
• MLflow GitHub Advisory: https://github.com/mlflow/mlflow/security/advisories/GHSA-xg73-94fp-g449
• Public POC: https://github.com/paultheal1en/CVE-2023-1177-PoC-reproduce.git

‍