CVE-2026-115886 in MLflow
Summary
by MITRE • 10/24/2026
MLflow is an open source AI engineering platform for agents, large language models, and machine learning models. From 3.12.0rc0 until 3.17.0, the scorer invoke, register, and GenAI evaluate endpoints, including unauthenticated POST /ajax-api/3.0/mlflow/scorer/invoke, accept serialized third-party scorer data that Scorer.model_validate_json resolves using a module-path allowlist without constraining the selected class or its constructor arguments. When optional trulens and trulens-providers-litellm packages are installed, an attacker can select mlflow.genai.scorers.trulens, choose a model URI outside MLflow's native provider registry so execution uses the LiteLLM fallback, and supply api_base and api_key values that cause the server to send an outbound request to an attacker-chosen or internal host with attacker-controlled headers and body. The vulnerable deserialization occurs before a tracking-store lookup or job submission. This issue is fixed in version 3.17.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in MLflow versions ranging from 3.12.0rc0 to 3.17.0 represents a critical security flaw rooted in insecure deserialization practices within the platform's scoring and evaluation endpoints. As an open-source AI engineering platform designed for managing agents, large language models, and machine learning workflows, MLflow exposes several API endpoints including scorer invoke, register, and GenAI evaluate. These endpoints accept serialized third-party scorer data which is processed by Scorer.model_validate_json. The core technical flaw lies in the validation mechanism used during this deserialization process. Specifically, while the system employs a module-path allowlist to restrict which Python modules can be loaded, it fails to constrain the specific classes selected from those allowed modules or their constructor arguments. This lack of granular control allows an attacker to manipulate the instantiation parameters of trusted classes in ways that were not anticipated by the developers, leading to unintended side effects during object initialization.
The operational impact of this vulnerability is significant due to its potential for Remote Code Execution and Server-Side Request Forgery scenarios. When optional packages such as trulens and trulens-providers-litellm are installed on the MLflow server, an attacker can exploit the deserialization flaw by selecting specific scorer classes like mlflow.genai.scorers.trulens. By providing a model URI that falls outside of MLflow's native provider registry, the system is forced to utilize the LiteLLM fallback mechanism. This pathway allows the attacker to supply arbitrary values for api_base and api_key parameters within the serialized payload. Consequently, when the server processes this data during object construction, it initiates an outbound HTTP request directed at a host chosen by the attacker or potentially internal network resources. Crucially, these requests include headers and body content that are entirely controlled by the attacker, facilitating potential data exfiltration, credential theft, or further lateral movement within the target infrastructure.
This vulnerability is classified under CWE-502 Deserialization of Untrusted Data because it involves processing input from an external source without sufficient validation before use in critical operations. The attack vector aligns with MITRE ATT&CK technique T1190 Exploit Public-Facing Application, as the flaw resides in endpoints that are accessible over a network and can be triggered by unauthenticated users via POST requests to paths such as /ajax-api/3.0/mlflow/scorer/invoke. The severity of this issue is compounded by the fact that the vulnerable deserialization occurs prior to any tracking-store lookup or job submission, meaning the malicious code executes early in the request lifecycle with elevated privileges relative to standard application logic. This timing allows the attacker to influence system behavior before security checks related to data persistence or task scheduling are applied.
To mitigate this risk, organizations running MLflow must immediately upgrade to version 3.17.0 where these deserialization constraints have been strengthened. In environments where upgrading is not immediately feasible, it is advisable to restrict network access to the affected API endpoints using firewalls or reverse proxy configurations that limit exposure to trusted IP addresses only. Additionally, administrators should ensure that optional packages like trulens and litellm providers are removed if they are not strictly required for business operations, thereby eliminating the specific code paths exploited by this vulnerability. Continuous monitoring of outbound network traffic from MLflow servers can also help detect anomalous connections indicative of exploitation attempts involving unauthorized api_base or api_key configurations.