MLflow CVE-2026-116691

Concrete prerequisites, all confirmed by the advisory and commit: the application must explicitly call mlflow.crewai.autolog() (autologging is opt-in, not a default), and a CrewAI Agent must use an LLM object that holds a plaintext credential as a field (e.g. created via LLM(api_key='sk-...')), on MLflow 2.19.0 through 3.16.x. Affected fields include llm, function_calling_llm, agent_executor, and crew, which are serialized via __dict__ into span attributes and mlflow.spanInputs. Disclosure further requires that some party can read the destination where traces land - the MLflow tracking backend or the configured OTLP endpoint; no provider request even needs to succeed, since the key is captured when instrumentation starts. Limiting factors that reduce real-world risk: the integration must be deliberately enabled, the key must be passed as an LLM field rather than sourced purely from environment variables, and realized impact depends on who has access to the trace/telemetry store. Upgrading to 3.17.0 stops new leakage but does not scrub keys already written, so previously exposed keys must be rotated and affected traces deleted or redacted.

Signals point to a genuine but moderate, non-urgent credential-exposure issue rather than a high-impact remote compromise. The NVD CVSS 3.1 base score is 6.5 (medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N - confidentiality-only impact, no integrity or availability effect. The AV:N/PR:L framing is somewhat nominal: this is a passive information-disclosure/logging flaw (CWE-200/312/532) where a CrewAI LLM object's api_key is serialized verbatim into MLflow trace spans, so the real 'attacker' is any party able to read the MLflow trace backend or the configured OTLP destination, not a classic remote exploiter sending packets to the host. EPSS is not provided in the input and cannot be cited. The vulnerability is not listed in CISA KEV and there is no indication of active exploitation. A public PoC reference exists in the GHSA advisory (a reproduction verified on MLflow 3.16.0 with CrewAI 1.15.18, showing the fake key in 5 attribute locations across 2 spans); it is not verified as working offensive exploit code, and PoC availability must not be conflated with active exploitation. No SSVC decision (Automatable / technical impact / exploitation) is supplied, so that framework cannot be applied; the only priority signal present is the vuln.today 'this_month' label, consistent with a medium-severity credential leak that warrants scheduled remediation and key rotation rather than emergency action. Net: a real priority for teams running the affected integration because leaked provider keys cross a trust boundary into observability telemetry, but the moderate CVSS and absence of KEV/EPSS data argue against treating it as an emergency.

A team enables mlflow.crewai.autolog() and runs a CrewAI Agent whose LLM was created with a plaintext provider key (e.g. LLM(api_key='sk-...')); MLflow automatically serializes the Agent's llm field and expands the Agent into mlflow.spanInputs, writing the key into trace spans. Anyone with read access to the MLflow tracking backend or the configured OTLP destination - internal MLflow users, observability operators, or a third-party telemetry provider - then reads the plaintext key and reuses it against the LLM provider account. A public PoC in the GHSA advisory demonstrates both the direct _get_agent_attributes() leak and end-to-end disclosure through MLflow's OTLP exporter.