CVE-2026-116691 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 2.19.0 until 3.17.0, mlflow.crewai.autolog() records CrewAI Agent objects without consistently sanitizing nested credential-bearing values. mlflow/crewai/autolog.py::_get_agent_attributes() converts the Agent llm field to a string that includes the provider API key, while mlflow/crewai/autolog.py::_construct_full_inputs() expands the Agent object into mlflow.spanInputs. Applications can therefore send plaintext provider credentials to the MLflow trace backend or a configured OTLP destination, where trace readers can obtain them. This issue is fixed in version 3.17.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified within the MLflow platform affects versions ranging from 2.19.0 through 3.17.0 and specifically impacts the integration with CrewAI agents via the mlflow.crewai.autolog() function. This feature is designed to automatically log telemetry data for machine learning workflows, but it contains a critical flaw in how it handles sensitive configuration details embedded within agent objects. The core technical issue lies in the insufficient sanitization of nested credential-bearing values when these objects are processed for logging purposes. Specifically, the internal method _get_agent_attributes() converts the language model llm field into a string representation that inadvertently includes the provider API key. This conversion process fails to strip or mask sensitive authentication tokens before they are passed further down the telemetry pipeline.
As the execution flow continues, the function _construct_full_inputs() expands the Agent object structure and maps it directly into mlflow.spanInputs for trace collection. Because the sanitization step was skipped during the initial attribute extraction, the plaintext API keys become part of the structured data payload sent to the MLflow trace backend or any configured OpenTelemetry Protocol destination. This results in the exfiltration of sensitive credentials from the application environment into logging systems that may not have equivalent security controls for protecting secrets at rest or in transit within their respective storage layers. The presence of these plaintext keys in logs creates a significant risk if those log stores are accessed by unauthorized users, including developers with broad read access to monitoring dashboards or external entities compromising the telemetry infrastructure.
From an operational impact perspective, this vulnerability allows attackers who gain access to MLflow traces or OpenTelemetry collectors to harvest valid API credentials for various large language model providers. These compromised keys can be used to impersonate legitimate services, incur unauthorized costs by consuming provider resources, or potentially access sensitive data processed through those models if the associated accounts have broader permissions. The risk is amplified because logging systems are often considered less secure than application codebases due to their high availability requirements and frequent exposure for debugging purposes. Consequently, this flaw represents a severe compromise of confidentiality within the AI engineering workflow, undermining the security posture of applications relying on MLflow for observability while using CrewAI agents with external LLM integrations.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor under the Common Weakness Enumeration framework, as it involves the accidental exposure of secret material through improper data handling practices. In terms of adversary tactics, this behavior facilitates Credential Access via Unsecured Logging within the MITRE ATT&CK framework, allowing threat actors to harvest secrets from system logs without needing direct access to application source code or configuration files. The issue has been addressed in version 3.17.0 through improved sanitization logic that ensures sensitive fields are masked or excluded before being serialized into trace inputs. Organizations running affected versions should upgrade immediately and rotate any API keys that may have been exposed during the period of vulnerability, while also auditing historical logs for potential leakage of credentials to mitigate ongoing risk.