---
id: "CVE-2026-116691"
kind: "vulnerability"
aliases: ["CVE-2026-116691", "GHSA-j7qq-vr8c-xvw3"]
title: "MLflow CrewAI autologging records LLM provider API keys in logged trace spans"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "mlflow", "fixed": ["3.17.0"], "affected": ">= 2.19.0, < 3.17.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-agents", "ai-tooling", "crewai", "cwe-200", "cwe-312", "cwe-532", "llm-apps", "mlflow", "python"]
not_affected_if: ["mlflow-3.17.0-or-later", "no-crewai-autolog"]
published_at: "2026-10-27T20:17:14+00:00"
first_seen_at: "2026-10-27T20:33:27+00:00"
updated_at: "2026-10-27T21:29:43+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116691", "first_seen_at": "2026-10-27T20:33:27+00:00"}, {"source": "ghsa", "url": "https://github.com/advisories/GHSA-j7qq-vr8c-xvw3", "first_seen_at": "2026-10-27T21:29:43+00:00"}]
---

# MLflow CrewAI autologging records LLM provider API keys in logged trace spans

When an application uses mlflow.crewai.autolog(), MLflow records CrewAI Agent objects, and the Agent's llm field is converted to a string that includes the provider API key. Anyone who can read the MLflow trace backend or a configured OTLP destination can obtain those plaintext provider credentials.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:mlflow affected >= 2.19.0, < 3.17.0 fixed 3.17.0

## How to check

- Run `pip show mlflow` and check whether the installed version is below `3.17.0`
- Search application code for `mlflow.crewai.autolog` to confirm CrewAI autologging is enabled
- Review stored traces or the OTLP destination for spanInputs containing provider API keys

## Fix

- Upgrade MLflow to `3.17.0` or later
- Rotate any provider API keys that were sent to MLflow traces or an OTLP destination while on an affected version
- Restrict read access to the MLflow trace backend and OTLP destination until traces are reviewed

## Timeline

- 2026-10-27T20:33:27+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-116691
- 2026-10-27T21:29:43+00:00 ghsa https://github.com/advisories/GHSA-j7qq-vr8c-xvw3

## From the sources

### Summary

`mlflow.crewai.autolog()` leaks CrewAI LLM provider API keys into MLflow trace telemetry.

When a CrewAI `Agent` is instrumented with MLflow autologging, MLflow serializes the agent's `__dict__` and converts its fields to strings. The `llm` field contains the CrewAI LLM object, whose string representation includes its `api_key` in plaintext.

As a result, an application that calls `mlflow.crewai.autolog()` can unintentionally send its LLM provider API key to the MLflow trace backend or configured OTLP destination.

The application does not need to explicitly log the credential or place it in a span attribute. The credential is extracted automatically by MLflow's instrumentation.

This was verified on **MLflow 3.16.0** with **CrewAI 1.15.18** using MLflow's own OTLP exporter. The fake credential appeared in **5 attribute locations across 2 spans**.

### Details

The primary issue is in:

`mlflow/crewai/autolog.py::_get_agent_attributes()`

The function walks the CrewAI `Agent.__dict__` and converts agent fields to strings. `tools` and `embedder` receive special handling, but credential-bearing objects such as the following are not sanitized:

* `llm`
* `function_calling_llm`
* `agent_executor`
* `crew`

For example, `agent.llm` is a CrewAI `LLM` object. In CrewAI 1.15.18, the underlying LLM model contains `api_key` as a normal field. Its string representation therefore contains the credential:

```text
llm_type='openai' model='gpt-4.1-mini' ... api_key='sk-proj-...' ...
```

MLflow subsequently stores this string as a span attribute.

There is an important indication that this is an unintended disclosure: MLflow's dedicated LLM attribute extraction already explicitly excludes `api_key` in `_get_llm_attributes()`. The LLM span therefore does not expose the credential, while the broader Agent `__dict__` serialization bypasses that protection.

There is also a second, independent serialization path in:

`mlflow/crewai/autolog.py::_construct_full_inputs()`

This code uses:

```python
v.__dict__ if hasattr(v, "__dict__") else v
```

on call arguments. During CrewAI execution, the `Agent` object is passed as an argument, causing its `__dict__` to be expanded and the credential-bearing LLM object to be included in `mlflow.spanInputs`.

Therefore, there are two independent leakage paths:

1. **Agent span attributes** through `_get_agent_attributes()`
2. **Span inputs** through `_construct_full_inputs()`

Fixing only the Agent attribute serialization would leave the `mlflow.spanInputs` path vulnerable.

A safer approach would be to avoid recursively serializing arbitrary object `__dict__` values. Agent telemetry should use an explicit allowlist of non-sensitive scalar fields, and credential-bearing objects such as `llm`, `function_calling_llm`, `agent_executor`, and `crew` should either be reduced to safe metadata or omitted.

Similarly, `_construct_full_inputs()` should not automatically expand arbitrary objects through `__dict__`, or the resulting values should pass through the same sanitization mechanism before being attached to a span.

### PoC

Environment:

```text
MLflow: 3.16.0
CrewAI: 1.15.18
Python: 3.12.3
opentelemetry-exporter-otlp-proto-http: 1.42.1
```

#### 1. Direct serialization proof

The following demonstrates the vulnerability without starting a Crew, making a network request, or requiring an MLflow server:

```python
import importlib
from crewai import LLM, Agent

autolog = importlib.import_module("mlflow.crewai.autolog")

llm = LLM(
    model="gpt-4.1-mini",
    api_key="sk-proj-EXAMPLE1234567890",
)

agent = Agent(
    role="r",
    goal="g",
    backstory="b",
    llm=llm,
)

attrs = autolog._get_agent_attributes(agent)

assert "sk-proj-EXAMPLE1234567890" in attrs["llm"]

print(attrs["llm"])
```

The output contains the API key in plaintext, for example:

```text
llm_type='openai' model='gpt-4.1-mini' ... api_key='sk-proj-EXAMPLE1234567890' ...
```

No provider request is required.

#### 2. End-to-end trace disclosure

The issue can also be reproduced through MLflow's actual OTLP exporter.

Configure a local OTLP HTTP receiver and set:

```bash
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://127.0.0.1:4318/v1/traces
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
export CREWAI_DISABLE_TELEMETRY=true
```

Then run:

```python
import mlflow

from crewai import Agent, Crew, LLM, Task

mlflow.crewai.autolog()

llm = LLM(
    model="gpt-4.1-mini",
    api_key="sk-proj-EXAMPLE1234567890",
)

agent = Agent(
    role="Support Responder",
    goal="Answer support questions",
    backstory="A support agent",
    llm=llm,
)

task = Task(
    description="Answer the user's question",
    expected_output="A response",
    agent=agent,
)

crew = Crew(
    agents=[agent],
    tasks=[task],
)

crew.kickoff()
```

A local OTLP receiver can decode the `ExportTraceServiceRequest` sent by MLflow.

The provider request is expected to fail because the credential is intentionally fake. This does not affect the vulnerability: the sensitive value is added to the MLflow span when the instrumentation starts, before the provider call succeeds or fails.

In the tested environment, the fake API key appeared in the exported telemetry in **5 locations across 2 spans**, including:

```text
Support Responder
  attributes.llm
  attributes.function_calling_llm
  attributes.agent_executor
  attributes.mlflow.spanInputs

Task.execute_sync
  attributes.mlflow.spanInputs
```

The captured value is produced by MLflow's actual telemetry/export path rather than being manually inserted into a span.

All credentials used in the reproduction are locally generated fake values. No real API credential is required.

### Impact

**Type:** Sensitive Information Disclosure / Credential Disclosure
**CWE:** CWE-532 — Insertion of Sensitive Information into Log File

Any application using `mlflow.crewai.autolog()` with a CrewAI `LLM` configured with an API key can unintentionally disclose that credential through MLflow traces.

The credential is written to trace telemetry even though the application does not explicitly log it.

Anyone with access to the MLflow trace storage or configured OTLP destination may therefore obtain the provider credential. Depending on the deployment, this can include MLflow users, observability operators, or third-party telemetry providers.

The leaked credential can then potentially be used against the corresponding LLM provider account, including for unauthorized API usage and associated costs.

The issue is particularly significant because the credential crosses a trust boundary: a provider API key intended for use by the application is automatically copied into observability telemetry where a broader set of users or systems may have access.

The vulnerability does not require the developer to intentionally log the secret. The only relevant prerequisite is enabling the CrewAI autologging integration.

### Patches

Fixed in MLflow 3.17.0 by #25845. `mlflow.crewai.autolog()` now reduces CrewAI LLM objects to their model name and drops credential-like keys before they are written to span attributes or `mlflow.spanInputs`.

### Remediation

- Upgrade to `mlflow>=3.17.0`.
- Upgrading stops new leakage but does not remove credentials already written. Rotate any LLM provider key that a CrewAI `LLM` object held (for example one passed as `LLM(api_key=...)`) while `mlflow.crewai.autolog()` was enabled on MLflow 2.19.0 through 3.16.x.
- Delete or redact the affected traces in the MLflow tracking backend and in any OTLP destination they were exported to. The key appears in Agent and Crew span attributes and in `mlflow.spanInputs`.

### Workarounds

If you cannot upgrade yet, disable CrewAI autologging with `mlflow.crewai.autolog(disable=True)`.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_