CVE-2026-116692 in Mlflow
Summary
by MITRE • 10/27/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, third-party scorer deserialization in mlflow/genai/scorers/base.py accepts request-selected descendants of THIRD_PARTY_SCORER_ALLOWED_MODULES rather than requiring an exact allowed module. A caller can use MLflow artifact endpoints to place a Python module beneath a writable allowed package and submit its module and class through /ajax-api/3.0/mlflow/scorer/invoke. Scorer.model_validate_json() imports the module and constructs the class before trace processing. Authentication-disabled deployments permit this code execution without credentials, while basic-auth deployments require a principal capable of creating an experiment and run and uploading artifacts. In either configuration, the allowed scorer package must be writable by the server process. 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/27/2026
The vulnerability identified within MLflow versions ranging from 3.12.0rc0 to 3.17.0 represents a critical insecure deserialization flaw located in the genai scorers subsystem, specifically within the base.py module responsible for handling third-party scorer implementations. This security defect stems from an overly permissive validation logic that accepts request-selected descendants of allowed modules rather than enforcing strict exact matches against a whitelist. In secure software design, particularly when dealing with dynamic code loading or serialization mechanisms, it is imperative to restrict input to explicitly defined safe classes to prevent the instantiation of arbitrary objects. By allowing subclasses of whitelisted modules, the application inadvertently opens a pathway for attackers to exploit Python's import system and object construction processes, leading to potential remote code execution under specific deployment configurations.
The operational mechanism of this exploitation involves an attacker leveraging MLflow artifact endpoints to upload a malicious Python module into a directory that is writable by the server process and falls beneath one of the allowed package paths. Once the malicious module is in place, the attacker submits its fully qualified module name and class identifier through the /ajax-api/3.0/mlflow/scorer/invoke endpoint. Upon receiving this request, the scorer.model_validate_json() function processes the input by importing the specified module and instantiating the requested class before any trace processing occurs. This sequence allows arbitrary code to be executed during the import and instantiation phases, as Python modules often execute top-level code upon loading, which can include system commands or other malicious payloads designed to compromise the host environment.
The severity of this vulnerability is heavily dependent on the authentication configuration of the MLflow deployment instance. In deployments where authentication is disabled, any unauthenticated actor with network access to the service can exploit this flaw to achieve remote code execution without providing credentials. This scenario poses an extreme risk as it allows complete compromise of the underlying infrastructure hosting the MLflow server. Conversely, in environments that employ basic-auth or other authentication mechanisms, exploitation requires a higher privilege level; specifically, the attacker must possess a principal capable of creating experiments and runs, as well as uploading artifacts to the writable allowed package directory. Despite this additional barrier, the risk remains significant for any organization running MLflow with permissive file system permissions on scorer directories.
This vulnerability aligns closely with CWE-502, which describes deserialization of untrusted data, a category known for enabling remote code execution when input is not properly validated before being processed by sensitive functions like Python's importlib or pickle.loads equivalents in other languages. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques related to command and script interpretation, as well as defense evasion through living-off-the-land binaries if the executed code leverages standard system utilities. The core failure lies in the lack of strict allowlisting for class instantiation, violating the principle of least privilege by permitting dynamic subclass resolution instead of fixed class references.
To mitigate this vulnerability, organizations must immediately upgrade to MLflow version 3.17.0 or later, where the deserialization logic has been corrected to require exact module and class matches rather than accepting descendants. For deployments that cannot be upgraded instantly due to compatibility constraints, a temporary mitigation involves ensuring that no writable directories exist within any of the allowed scorer package paths on the server file system. Additionally, enforcing strict authentication policies ensures that only trusted users with minimal necessary privileges can interact with artifact upload endpoints and scorer invocation APIs. Regular auditing of directory permissions and continuous monitoring for unusual import patterns or unexpected process executions can further reduce the attack surface associated with dynamic code loading features in AI engineering platforms.