CVE-2026-69146 in MLflow
Summary
by MITRE • 08/18/2026
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 3.13.0 until 3.15.0, LogInputs is absent from BEFORE_REQUEST_HANDLERS in the mlflow/server/auth package, allowing any authenticated user to call POST /api/2.0/mlflow/runs/log-inputs for another user's run_id and inject attacker-controlled DatasetInput records into the dataset_inputs lineage metadata without UPDATE permission. This issue is fixed in version 3.15.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within MLflow versions ranging from 3.13.0 to 3.15.0 represents a critical authorization bypass that undermines the integrity of machine learning lineage tracking and data provenance. MLflow serves as a foundational platform for managing the end-to-end lifecycle of AI engineering, including agents, large language models, and traditional machine learning algorithms. A core component of this ecosystem is the ability to log inputs associated with specific model runs, which creates an immutable record of the dataset used during training or inference. This lineage metadata is essential for reproducibility, debugging, and compliance in regulated industries. The flaw resides specifically within the server authentication package, where a configuration error regarding request handlers allows unauthorized manipulation of this critical data structure.
The technical root cause stems from the absence of LogInputs functionality within the BEFORE_REQUEST_HANDLERS list in the mlflow/server/auth module for the affected versions. In typical web application security architectures, before-request handlers are executed prior to routing requests to their specific endpoint logic and often serve as a gatekeeping mechanism for authentication and authorization checks. By omitting the log-inputs handler from this pre-processing stage, the system fails to enforce proper access control validation at the earliest possible point in the request lifecycle. Consequently, when an authenticated user submits a POST request to the /api/2.0/mlflow/runs/log-inputs endpoint with a target run_id belonging to another user, the server processes the request without verifying whether the caller possesses UPDATE permissions for that specific resource. This design flaw effectively decouples authentication from authorization in this specific context, allowing any valid session token to be used as a key to modify arbitrary resources within the platform.
The operational impact of this vulnerability is severe due to its implications for data integrity and model security. An attacker can inject malicious DatasetInput records into another user's run lineage metadata without needing explicit UPDATE permissions on that run. This capability enables several adversarial scenarios, including data poisoning where an adversary introduces corrupted or biased input data into a victim's training pipeline, potentially degrading the performance of their models in production. Furthermore, it allows for false attribution, where an attacker can falsely associate specific datasets with another user’s experiments, thereby corrupting audit trails and making forensic analysis difficult. In environments relying on MLflow for compliance reporting, this manipulation could lead to significant regulatory violations by altering the recorded history of model development processes.
This vulnerability aligns closely with CWE-269, which describes Improper Privilege Assignment, as it allows a lower-privileged user to perform actions reserved for higher-privileged roles or resource owners. Additionally, from an offensive security perspective, this behavior maps to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1496 Resource Hijacking if the injected inputs are used to manipulate computational resources or model outputs. The lack of proper authorization checks on a write operation constitutes a classic broken access control scenario that is frequently exploited in modern web applications.
To mitigate this risk, organizations must immediately upgrade MLflow to version 3.15.0 or later, where the LogInputs handler has been correctly integrated into the BEFORE_REQUEST_HANDLERS sequence. This ensures that authorization checks are performed before any data modification occurs. For environments unable to patch immediately due to dependency constraints, temporary mitigations should include restricting network access to the MLflow server to only trusted internal subnets and implementing strict API gateway rules that validate user permissions against resource ownership at the proxy level rather than relying solely on application-level logic. Regular audits of request handler configurations in authentication modules are also recommended to prevent similar omissions in future updates or custom deployments.