This is not the first time MLflow has been caught with this class of vulnerability. It is not the second or third time either. CVE-2026-2033 represents at least the tenth documented path traversal or directory traversal vulnerability in the platform since 2023, continuing a pattern that raises serious questions about input validation practices across MLflow’s codebase and the security posture of organizations deploying it in production AI/ML environments.
This article breaks down the vulnerability, reconstructs the attack chain, maps the historical pattern of similar flaws, and provides actionable defensive guidance.
The Vulnerability: What CVE-2026-2033 Actually Does
According to the ZDI advisory, CVE-2026-2033 resides in how the MLflow Tracking Server handles artifact file paths. The advisory states that the specific flaw exists within the handling of artifact file paths and that the issue results from the lack of proper validation of a user-supplied path prior to using it in file operations.
CVSS v3.1 Score: 8.1 (High) — Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — Network-exploitable, no authentication required, high impact across confidentiality, integrity, and availability.
The vulnerability was reported to MLflow on July 31, 2025, by researcher Muhammad Fadilullah Dzaki. Coordinated public disclosure followed on February 13, 2026, roughly six and a half months later. MLflow has issued a patch.
Understanding the Attack Chain
While the ZDI advisory does not publish a full proof-of-concept, the technical description combined with MLflow’s well-documented history of similar flaws provides enough detail to understand how this works.
MLflow’s Tracking Server manages artifacts — files generated during machine learning experiments, including trained models, datasets, configuration files, and evaluation outputs. When a user or process requests an artifact, the server resolves a file path and returns the corresponding file. The vulnerability exists because the server fails to properly sanitize user-supplied path values before passing them into file system operations.
A directory traversal attack exploits this by injecting sequences like ../ into the path parameter. Instead of resolving to a file within the intended artifact directory, the manipulated path escapes upward through the directory tree, reaching files anywhere on the server’s filesystem that the service account has permission to access.
In prior MLflow path traversal vulnerabilities, researchers demonstrated that attackers could read sensitive files like /etc/passwd, SSH private keys, cloud provider credentials, and environment variables. CVE-2026-2033 goes further — the advisory classifies it as a remote code execution vulnerability, not just an information disclosure or file read.
The escalation from file read to code execution in MLflow typically works through one of two mechanisms. First, if the attacker can write files (not just read them), they can place a malicious Python file in a location that gets loaded by the MLflow process or the Python interpreter — for example, a .py or .pth file in a directory within sys.path. Second, the attacker may be able to manipulate model artifacts or configuration files to inject code that executes when MLflow processes or serves them, exploiting the platform’s model deserialization pipeline.
The result is that an unauthenticated attacker with network access to the MLflow Tracking Server can potentially achieve full code execution in the context of the service account, compromising the server and everything it has access to.
MLflow’s History of Path Traversal Vulnerabilities: A Pattern, Not an Anomaly
CVE-2026-2033 is not an isolated incident. MLflow has accumulated a troubling track record of path traversal and directory traversal vulnerabilities dating back to early 2023. Here is a timeline of the documented flaws:
Path traversal in static file serving, allowing attackers to access arbitrary files. One of the first widely reported path traversal issues in MLflow.
Relative path traversal in versions prior to 2.3.1, potentially exposing local server files.
Another path traversal variant in versions prior to 2.3.1.
Directory traversal via the
validate_path_is_safe() function due to improper handling of absolute Windows paths with forward slash separators.
Path traversal in versions prior to 2.9.2.
Path traversal using query parameters, which would become the starting point for multiple bypass vulnerabilities.
Exploitable for command execution, allowing attackers to access data and model information.
Attackers could access arbitrary files by crafting HTTP POST requests with specially crafted
artifact_location and source parameters, using # instead of ? in URIs.
Path traversal in the artifact deletion functionality through double decoding in the
_delete_artifact_mlflow_artifacts handler, allowing arbitrary directory deletion.
Path traversal via semicolon character smuggling in URL parameters.
Another variant exploiting the fragment component of URIs to read arbitrary files. Similar to CVE-2023-6909 but using a different URI component.
Local file inclusion via URI fragment manipulation. MLflow parsed the raw HTTP request line and inadvertently included the fragment during artifact path resolution, bypassing earlier fixes.
Path traversal due to improper URI parsing in the
is_local_uri function, which failed to properly handle URIs with empty or file schemes.
Identified as a bypass for CVE-2023-6909, using
# characters to insert paths into the fragment and skip validation entirely.
The temporary directory for creating Python virtual environments was assigned world-writable permissions (0o777), enabling race condition exploitation for arbitrary code execution.
Yet another directory traversal in the model creation process, again through unsanitized
source parameters.
DNS rebinding vulnerability due to missing Origin header validation, allowing malicious websites to execute unauthorized calls against REST endpoints for data exfiltration and manipulation.
The vulnerability under discussion. Artifact handler directory traversal leading to remote code execution.
This list is not exhaustive. It does not include the multiple deserialization vulnerabilities (CVE-2024-37052 through CVE-2024-37061) that also enable code execution through maliciously uploaded models targeting scikit-learn, PyTorch, TensorFlow, LightGBM, and pmdarima.
Recurring Bypass Pattern: Fixes for individual path traversal CVEs have repeatedly been bypassed by subsequent vulnerabilities. CVE-2023-6909 was bypassed by CVE-2024-3848, which was then bypassed by CVE-2024-2928. Each patch addressed the specific technique the researcher used, but failed to implement comprehensive input validation that would prevent the entire class of attack. The same general mechanism — unsanitized user input in file path operations — keeps appearing across different components: artifact handling, experiment creation, model version creation, and artifact deletion.
Why This Matters: MLflow’s Role in AI/ML Infrastructure
The severity of these vulnerabilities is amplified by the role MLflow plays in modern organizations. MLflow is the most widely adopted open-source MLOps platform, with over 30 million monthly downloads and thousands of organizations using the platform according to public tracking data. Deployed by research teams, startups, and enterprises alike, it sits at the center of the machine learning lifecycle, managing experiment tracking, model registration, artifact storage, and increasingly, generative AI application governance.
A compromised MLflow Tracking Server is not just one breached system. It is a gateway to the organization’s entire AI/ML pipeline. The artifacts stored on an MLflow server can include trained model weights (intellectual property worth millions in R&D investment), training datasets (potentially containing sensitive customer data, PII, or proprietary business data), API keys and cloud credentials (used by MLflow to access cloud storage backends like S3, Azure Blob Storage, or GCS), and experiment metadata (revealing strategic priorities, capability gaps, and competitive intelligence).
An attacker who gains code execution on the MLflow server can tamper with model artifacts, introducing backdoors into production AI systems. They can exfiltrate proprietary models and data. They can pivot laterally into connected cloud infrastructure using stored credentials. They can poison training data or evaluation results, undermining the integrity of the entire ML workflow.
This risk is compounded by deployment realities. MLflow’s official documentation notes that its Tracking Server listens on localhost by default, but the moment teams need collaboration, they bind to 0.0.0.0 for network access. Prior to version 3.5.0, MLflow lacked built-in security middleware for DNS rebinding, CORS, or clickjacking protection. Authentication is not enabled by default and requires explicit configuration through environment variables or a reverse proxy. Many deployments — particularly in development and staging environments, or in organizations without mature security practices for ML infrastructure — run MLflow exposed to internal networks or even the public internet with minimal access controls.
Defensive Guidance: What to Do Now
0.0.0.0, restrict access through firewall rules, security groups, or network segmentation.
--allowed-hosts and --cors-allowed-origins.
../ sequences, URI fragments with path characters, encoded path separators, or requests for files outside expected artifact directories.
MLFLOW_CREATE_MODEL_VERSION_SOURCE_VALIDATION_REGEX environment variable, which enforces a regular expression pattern on model version sources. Configure this to restrict sources to approved locations, preventing attackers from registering model versions with traversal-laden source paths.
The Bigger Picture: AI Infrastructure Is Security Infrastructure
CVE-2026-2033 is a reminder that AI and ML platforms are not exempt from the same security fundamentals that apply to every other piece of infrastructure. Input validation, access control, network segmentation, and least privilege are not optional just because the software is managing experiments instead of serving web pages.
The recurring nature of path traversal vulnerabilities in MLflow specifically points to something deeper than individual bugs. When the same vulnerability class appears more than a dozen times across three years, with patches repeatedly bypassed by researchers finding new traversal techniques, it suggests that the platform needs a comprehensive architectural review of how it handles file paths, not another game of whack-a-mole with individual bypass techniques.
MLflow’s maintainers deserve credit for participating in coordinated disclosure through the Zero Day Initiative and releasing patches when vulnerabilities are reported. The introduction of security middleware in version 3.5.0 shows awareness of the problem. But the pace of discovery continues to outstrip the pace of architectural remediation.
For organizations deploying MLflow, the lesson is clear: treat this platform as security-critical infrastructure. Harden it accordingly. Do not assume that an internal-facing ML tool is any less of a target than a public-facing web application. Attackers who breach AI infrastructure gain access to some of the most valuable and sensitive assets an organization possesses.
Sources and References
- ZDI-26-105 Advisory: https://www.zerodayinitiative.com/advisories/ZDI-26-105/
- CVE-2026-2033: https://www.cve.org/CVERecord?id=CVE-2026-2033
- MLflow Security Overview (GitHub): https://github.com/mlflow/mlflow/security
- MLflow Network Security Documentation: https://mlflow.org/docs/latest/self-hosting/security/network/
- MLflow Tracking Server Documentation: https://mlflow.org/docs/latest/self-hosting/architecture/tracking-server/
- Snyk MLflow Vulnerability Database: https://security.snyk.io/package/pip/mlflow
- Meterian MLflow Component Analysis: https://www.meterian.io/components/python/mlflow/2.0.0/
- CVE-2024-2928 Analysis (OffSec): https://www.offsec.com/blog/cve-2024-2928/
- CVE-2025-11201 Analysis (ZeroPath): https://zeropath.com/blog/cve-2025-11201-mlflow-directory-traversal-rce
- MLflow GitHub Issue ZDI-CAN-26921: https://github.com/mlflow/mlflow/issues/16019
This article is provided for defensive cybersecurity awareness and education purposes. The technical details described here are drawn from publicly disclosed advisories and are intended to help security teams understand and defend against this vulnerability class.