CVE-2026-2614

What it actually does

CVE-2026-2614 is an unauthenticated arbitrary file read vulnerability in MLflow 3.9.0 and earlier. The flaw is in the model version creation flow: a CreateModelVersion request containing the tag `mlflow.prompt.is_prompt` can bypass normal source path validation and store an attacker-controlled local filesystem path as the model version source. A later artifact retrieval request through `get_model_version_artifact_handler()` uses that stored source path to serve files without revalidating whether the model version is a prompt, allowing the attacker to read files accessible to the MLflow server process. Integrity and availability are not directly impacted by the vulnerability as described, but confidentiality can be fully compromised for local files readable by the service account.

Why it matters to the business

An internet- or network-accessible MLflow tracking/model registry server running a vulnerable version can expose sensitive files without authentication. Depending on deployment, this may include application secrets, cloud credentials, API tokens, SSH keys, service configuration, model registry metadata, environment files, and other files readable by the MLflow process. Exposure of those secrets can lead to follow-on compromise of cloud accounts, CI/CD systems, data stores, model artifacts, or internal services. Although the EPSS score is currently low and there is no known CISA KEV listing or public exploit maturity reported, the vulnerability is remotely exploitable without credentials and has high confidentiality impact, so exposed MLflow services should be prioritized for upgrade.

How an attack unfolds

An attacker first identifies an MLflow server with the model registry API exposed. Without authenticating, the attacker submits a CreateModelVersion request that includes the special tag `mlflow.prompt.is_prompt` and sets the model version source to a local filesystem path, such as a sensitive configuration file or directory on the server. Because the prompt tag causes the vulnerable handler to bypass source path validation, the server records the attacker-supplied local path as the model version source. The attacker then calls the model version artifact retrieval endpoint for that model version. The artifact handler trusts the stored source and serves files from the referenced local path without confirming that the prompt-specific handling is safe for artifact retrieval. By repeating this process with different paths, the attacker can enumerate and retrieve files readable by the MLflow server process.

How to fix it

Upgrade MLflow to version 3.10.0 or later, which fixes the vulnerable source path validation and artifact retrieval behavior. If immediate upgrade is not possible, restrict network access to MLflow servers to trusted users and internal networks only, place the service behind strong authentication and authorization controls, and block unauthenticated access to model registry and artifact endpoints. Run MLflow under a dedicated low-privilege service account with the minimum filesystem permissions required, and ensure secrets are not stored in files readable by the MLflow process. Review reverse proxy, API gateway, and ingress rules to confirm MLflow is not exposed publicly. Treat any potentially exposed secrets readable by the MLflow process as compromised until investigation proves otherwise.

How to confirm the fix worked

Confirm the running MLflow version is 3.10.0 or later by checking package metadata, container image manifests, dependency lock files, or `mlflow --version` output. Verify that no deployed virtual environment, container image, notebook environment, or ML platform image still contains MLflow 3.9.0 or earlier. Test access controls by confirming unauthenticated users cannot reach model registry creation or artifact download endpoints. Where safe and authorized, perform a negative validation test against a non-sensitive path to confirm CreateModelVersion requests cannot store arbitrary local filesystem paths via the `mlflow.prompt.is_prompt` tag and subsequently retrieve them as artifacts. Review filesystem permissions for the MLflow service account to ensure it cannot read sensitive host files beyond its required artifact and metadata locations.

Typical attack path

1. Discover an exposed MLflow tracking/model registry service running version 3.9.0 or earlier.
2. Send an unauthenticated CreateModelVersion API request for a new model version.
3. Include the tag `mlflow.prompt.is_prompt` in the request to trigger the validation bypass behavior.
4. Set the model version source field to a targeted local filesystem path on the MLflow server.
5. Request artifacts for the created model version through the artifact retrieval API.
6. Download files served from the attacker-controlled local path.
7. Repeat with additional common sensitive paths to obtain credentials, configuration, tokens, or keys for follow-on access.

How to detect it

Investigate MLflow application logs, reverse proxy logs, ingress controller logs, API gateway logs, WAF logs, container stdout/stderr, and host audit logs for unauthenticated or unusual model registry activity. Focus on sequences where a model version is created and then artifacts are retrieved for that same model version shortly afterward. Look for CreateModelVersion requests containing the tag `mlflow.prompt.is_prompt`, source values that resemble absolute local paths, path traversal strings, or references to sensitive files and directories. Review access to endpoints associated with model version creation and artifact retrieval, including REST API paths and any proxy-normalized equivalents. On hosts and containers, examine file access telemetry, EDR events, Linux auditd logs, and process monitoring for the MLflow process reading unusual files such as `/etc/passwd`, `/etc/shadow`, environment files, SSH keys, cloud credential files, Kubernetes service account tokens, or application configuration files. If suspicious artifact downloads are found, correlate the source IP, user agent, requested model/version, timestamps, response sizes, and subsequent authentication or cloud API activity using any credentials that may have been exposed.

• mlflow.prompt.is_prompt
• CreateModelVersion
• get_model_version_artifact
• /api/2.0/mlflow/model-versions/create
• /api/2.0/mlflow/model-versions/get-artifact
• /ajax-api/2.0/mlflow/model-versions/create
• /ajax-api/2.0/mlflow/model-versions/get-artifact
• source=/etc/passwd
• source=/etc/shadow
• source=/proc/self/environ
• source=/root/.ssh/id_rsa
• source=/home/
• source=/var/run/secrets/kubernetes.io/serviceaccount/token
• source=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
• source=/app/.env
• source=.env
• /etc/passwd
• /proc/self/environ
• /var/run/secrets/kubernetes.io/serviceaccount/token
• ../../
• ..%2f
• %2e%2e%2f

What your security team should do

• Upgrade all MLflow deployments to version 3.10.0 or later as the primary remediation.
• Immediately restrict external access to MLflow services, especially model registry and artifact endpoints, until all instances are verified patched.
• Inventory container images, virtual environments, notebooks, ML platforms, and downstream services that bundle MLflow 3.9.0 or earlier.
• Review MLflow access logs for suspicious unauthenticated model version creation followed by artifact download activity.
• Search logs for requests or payloads containing `mlflow.prompt.is_prompt` combined with local filesystem paths such as `/etc/passwd`, `/proc/self/environ`, `.env`, SSH keys, cloud credential paths, or Kubernetes service account tokens.
• Rotate credentials, tokens, API keys, and secrets that were stored in files readable by the MLflow server process if exploitation is suspected or cannot be ruled out.
• Run MLflow with least-privilege filesystem permissions and move secrets out of locations readable by the MLflow process.
• Add SIEM detections for suspicious MLflow API calls that create model versions with prompt tags and abnormal source paths.