CVE-2026-2033

What it actually does

This is an unauthenticated path traversal flaw in the MLflow Tracking Server artifact handling logic. The server accepts attacker-controlled artifact file paths without sufficiently canonicalizing and restricting them to the intended artifact directory. By supplying traversal sequences or otherwise crafted paths, a remote attacker can cause the service to read, write, or manipulate files outside the expected artifact root. In exploitable configurations, this can be chained into arbitrary code execution in the context of the MLflow Tracking Server service account, resulting in compromise of confidentiality, integrity, and availability for files and processes accessible to that account.

Why it matters to the business

An exposed vulnerable MLflow Tracking Server can allow an unauthenticated attacker to take control of the service account, tamper with machine-learning experiment artifacts, steal model data or credentials available to the process, disrupt experiment tracking, and potentially pivot further into connected infrastructure. The CVSS score is high, but the listed attack complexity is high and EPSS is currently low, suggesting broad exploitation is not yet strongly indicated; however, unauthenticated remote code execution in model/experiment infrastructure should still be treated as a priority, especially for internet-exposed systems or shared ML platforms. The affected package list includes Chainguard and Wolfi downstream packages, so organizations should verify not only direct MLflow deployments but also container images and dependent packages that may bundle vulnerable components.

How an attack unfolds

An attacker first identifies an accessible MLflow Tracking Server or a product/container image exposing the affected artifact handler. Because authentication is not required, the attacker can directly interact with artifact-related endpoints. They submit crafted artifact paths containing traversal patterns or path forms that escape the intended artifact storage directory. If the server performs file operations using the untrusted path, the attacker can access or modify files outside the artifact root. To achieve code execution, the attacker targets writable locations or files that influence application execution, startup behavior, plugins, scripts, serialized objects, or other files interpreted by the service or its runtime. Successful exploitation executes attacker-controlled code with the permissions of the MLflow service account, enabling data theft, artifact tampering, persistence, or lateral movement depending on the privileges and network access of that account.

How to fix it

Upgrade affected packages to fixed versions or later: dynamic-localpv-provisioner (Chainguard) to 3.4.1-r3 or later; dynamic-localpv-provisioner (Wolfi) to 3.4.1-r3 or later; prometheus-postgres-exporter-0.10 (Chainguard) to 0.10.1-r32 or later; dynamic-localpv-provisioner-fips (Chainguard) to 3.5.0-r0 or later. For MLflow Tracking Server deployments, update to a vendor-provided fixed release once available in the deployed distribution, rebuild container images, and redeploy running services so patched artifacts are actually in use. If immediate patching is not possible, restrict network access to trusted clients, place the service behind authentication and authorization controls, disable public exposure of artifact endpoints, enforce least privilege on the service account, mount artifact storage with the minimum required permissions, and monitor/block path traversal patterns at reverse proxies or WAFs as a temporary compensating control.

How to confirm the fix worked

Confirm package versions in running hosts and container images match or exceed the fixed versions listed for the affected distribution. Rebuild and rescan images to ensure older vulnerable layers are not still deployed. Validate that the running service binary/package is the patched version, not only that the base image was updated. Test exposure by verifying MLflow Tracking Server artifact endpoints are not reachable from untrusted networks and require appropriate access controls. Where safe and authorized, perform a non-destructive path traversal validation against artifact endpoints using benign traversal probes and confirm the server rejects attempts to access paths outside the configured artifact root. Review file permissions to ensure the service account cannot write to startup, plugin, interpreter, cron, shell profile, or other code-loading locations.

Typical attack path

1. Discover an exposed MLflow Tracking Server or an affected downstream package/container that includes the vulnerable artifact handling code.
2. Probe artifact upload, download, or file-handling endpoints with crafted path traversal payloads.
3. Confirm that paths can escape the intended artifact directory by reading or writing a controlled file outside the artifact root.
4. Identify files or directories writable by the MLflow service account that can influence code execution or service behavior.
5. Write or overwrite attacker-controlled content in a location that is later executed, imported, deserialized, or loaded by the service/runtime.
6. Trigger or wait for the affected service to execute the modified content.
7. Use code execution under the service account to access ML artifacts, credentials, environment variables, local files, or connected services.

How to detect it

Review MLflow Tracking Server access logs, reverse proxy logs, API gateway logs, WAF events, and application logs for unauthenticated artifact requests containing traversal patterns or encoded traversal characters. Focus on artifact upload, download, list, and file operation endpoints, especially requests containing ../, ..%2f, %2e%2e, backslash traversal, absolute paths, URL double-encoding, or attempts to reference sensitive system files. Examine filesystem audit logs, EDR telemetry, and container runtime events for the MLflow service account writing outside the configured artifact root, modifying startup scripts, Python modules, shell profiles, cron locations, service files, or other executable/configuration paths. Look for child processes spawned unexpectedly by the MLflow service process, outbound network connections from the service account, new files in temporary directories, and access to credential files or cloud metadata endpoints. Because no public exploit maturity is indicated and no named threat actors are provided, prioritize generic path traversal and post-exploitation behavior rather than actor-specific signatures.

• ../
• ..%2f
• ..%2F
• %2e%2e%2f
• %2e%2e/
• ..\\
• %2e%2e%5c
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• /root/.ssh/authorized_keys
• ~/.ssh/authorized_keys
• /etc/cron.d/
• /etc/crontab
• /var/spool/cron/
• /etc/systemd/system/
• /tmp/
• /var/tmp/
• /dev/shm/
• artifact
• artifacts
• mlflow

What your security team should do

• Prioritize patching internet-facing or unauthenticated MLflow Tracking Server deployments and affected container images first.
• Upgrade affected Chainguard/Wolfi packages to the fixed versions: dynamic-localpv-provisioner 3.4.1-r3, prometheus-postgres-exporter-0.10 0.10.1-r32, and dynamic-localpv-provisioner-fips 3.5.0-r0 as applicable.
• Inventory MLflow Tracking Server instances, derived images, and downstream packages to identify indirect exposure through bundled vulnerable components.
• Temporarily restrict artifact endpoints to trusted networks and enforce authentication until patching is complete.
• Review artifact storage, service account permissions, and filesystem mounts to reduce the impact of arbitrary file read/write or code execution.
• Search logs and forensic artifacts for traversal attempts and suspicious writes to executable or configuration paths before closing the incident.
• Add regression tests or security controls that canonicalize artifact paths and enforce containment under the configured artifact root.