MLflow CrewAI tracing leaked API keys into telemetry — upgrading does not remove old secrets

On October 13, 2026, MLflow published security advisory GHSA-j7qq-vr8c-xvw3 (CVSS 6.5, moderate) describing a sensitive-information disclosure in mlflow.crewai.autolog(). Affected MLflow versions are >=2.19.0 and <3.17.0. The instrumentation serialized CrewAI Agent and Crew objects including LLM provider api_key fields into trace attributes and span inputs, even when application code never explicitly logged credentials. The key could reach MLflow trace storage or a configured OpenTelemetry OTLP exporter. MLflow 3.17.0, released October 7, includes fix PR #25845, which sanitizes LLM objects and credential-like fields across the affected paths. The advisory recommends upgrading, rotating any exposed provider keys and deleting or redacting old traces. A small open-source tool called Weir surfaced the issue through canary-based credential tracking, but its broader detection claims are not independently benchmarked.

Observability systems often have wider access than application secret stores. A developer can keep a key out of application logs yet leak it through automatic object serialization inside AI-agent tracing. Updating MLflow stops new writes on the affected integration but cannot revoke a credential already copied to a telemetry backend or third-party collector. For AI SaaS operators, this is a concrete example of tracing and logging becoming a second secrets-management perimeter, with direct risks of unauthorised API use and billing exposure.

The MLflow advisory documents that CrewAI Agent.__dict__ and LLM object representations were serialised into span attributes. A second path expanded object __dict__ into mlflow.spanInputs; Crew attributes could also carry credential-bearing LLM objects. The dedicated LLM attribute path already excluded api_key, but the broader Agent, Crew and input paths bypassed it. The report reproduced a fake key in five attributes across two spans using MLflow 3.16.0 and CrewAI 1.15.18 with an OTLP exporter.

The advisory covers MLflow 2.19.0 through 3.16.x and identifies 3.17.0 as the first patched version. Maintainers' PR #25845 replaces selective handling with a recursive sanitizer, reduces CrewAI LLM objects to safe model metadata and filters credential-like keys in attributes and span inputs. The PR reports seven new regression tests that failed before the fix and passed after it. These are maintainer tests and an advisory reproduction, not an independent deployment-wide audit.

Operators should upgrade to MLflow 3.17.0 or later for this particular flaw. Then determine whether CrewAI autologging ran while keys were present, rotate affected LLM provider credentials, and purge or redact affected spans from both the MLflow tracking backend and downstream OTLP destinations. If upgrading is delayed, the advisory suggests disabling CrewAI autologging with mlflow.crewai.autolog(disable=True). Treat telemetry exports and backups according to retention and access policies.

The open-source Weir project describes placing synthetic provider keys in agent environments, executing real agent flows, then checking whether those values appear in spans, logs, model inputs or downstream services. Its repository links to the MLflow advisory, which credits its author as reporter. That supports this particular discovery; it does not establish the tool's claimed general reliability or safety across all frameworks. Test with fake keys rather than exposing real secrets to a new scanner.

MLflow has other October advisories with different affected versions and mitigations. In particular, the FileStore trace-ID path-traversal advisory CVE-2026-53995 names 3.17.2 as patched, but the upstream fix PRs' merge dates and the 3.17.2 release date appear inconsistent. This dossier's verified 3.17.0 recommendation applies only to the CrewAI credential leak; do not infer it resolves unrelated MLflow vulnerabilities.