GHSA-83fm-w79m-64r5

What it actually does

Unauthenticated path traversal in the MLflow tracking server and UI lets a remote client cause the process to open and return arbitrary files the service account can read. User-supplied path components used when serving artifacts or static content were not confined to a trusted base directory, so requests can escape the intended store. Direct impact is confidentiality of host files and stored ML artifacts; the flaw does not by itself provide write access, code execution, or denial of service.

Why it matters to the business

Unpatched MLflow servers can leak proprietary models, experiment data, and any secrets co-located on the host such as cloud keys, tokens, and configuration files, enabling intellectual-property theft, unauthorized cloud use, and compliance exposure. The issue is not in CISA KEV, has no reported ransomware use, and public exploit maturity is none, but it has been public since May 2023. Remaining instances below 2.3.1—especially those reachable without authentication—are an overdue confidentiality risk rather than an emergency zero-day.

How an attack unfolds

An attacker locates a network-reachable MLflow tracking or UI service, which historically often listened without authentication. They send HTTP requests to artifact-download or static-file routes with path values that resolve outside the intended storage root. The server follows those paths and returns file contents in the response. Stolen material commonly includes environment files, credential files, or private model artifacts, which can then be reused against cloud accounts, source control, or internal APIs. Privileged credentials are not required if the service is exposed and unauthenticated.

How to fix it

Upgrade the mlflow PyPI package to 2.3.1 or later and restart every mlflow server and mlflow ui process so they are not still serving an old environment. Do not publish tracking or UI ports to untrusted networks; bind to localhost or place them behind an authenticating reverse proxy. Enable MLflow authentication where available. Run the service under a dedicated low-privilege account that cannot read cloud credential files, SSH keys, or unrelated data directories. Rotate any secrets that resided on hosts that ran a vulnerable version while reachable.

How to confirm the fix worked

On every host that runs MLflow, inspect the installed package version with pip show mlflow or the project lockfile and confirm it is 2.3.1 or newer. Verify running processes were restarted after the upgrade. Confirm tracking and UI listeners are not published to untrusted networks and that authentication is required. Prefer version, listener, and permission checks over attempting to retrieve files through the HTTP API.

Typical attack path

1. Discover an MLflow tracking or UI HTTP service on an internal network or the internet
2. Determine that the instance is unauthenticated or weakly authenticated and likely older than 2.3.1
3. Request artifact or static-file endpoints using path values that escape the storage root
4. Collect returned files of interest such as credentials, configuration, models, or source
5. Reuse stolen secrets against cloud providers, source-control systems, or internal APIs

How to detect it

There is no CISA KEV listing, no associated ransomware campaign, and exploit maturity is none, so widespread confirmed exploitation is not documented; opportunistic scanning of exposed MLflow ports still occurs. Review HTTP access logs and reverse-proxy logs for the MLflow tracking or UI listener for the full window a version below 2.3.1 was reachable. Look for requests to artifact-get and static-file routes whose path or query parameters contain directory-ascent sequences or encoded equivalents, especially those that returned HTTP 200 with unexpected content. On the host, correlate the mlflow Python process with reads of credential or configuration files outside the artifact store. Cloud provider logs may show later use of keys that were stored on the same machine.

• mlflow server
• mlflow ui
• /get-artifact
• /ajax-api/2.0/mlflow/artifacts
• /model-versions/get-artifact
• %2e%2e%2f
• ..%2f
• %2e%2e/

What your security team should do

• Inventory all MLflow tracking servers and UIs and flag any instance below 2.3.1
• Upgrade those instances to mlflow 2.3.1 or later and restart the services
• Remove public or unauthenticated exposure of tracking and UI ports; require authentication and network allowlists
• Constrain the MLflow process account so it cannot read unrelated secrets or host files
• Rotate credentials and review cloud audit logs for hosts that ran a vulnerable, reachable instance
• Add MLflow version and exposure checks to ongoing ML-platform hygiene, since lab and tracking servers are often left unpatched