Skip to main content
Applies to:
  • Plan -
  • Deployment -

​
Summary

An implementation bug in Braintrust-maintained LiteLLM instrumentation could cause provider credentials passed directly to LiteLLM calls to be stored in Braintrust span metadata. The GitHub security advisory is the canonical source for affected versions, the trace detection query, workarounds, and technical references. This article answers common questions about the issue.
If your application is affected, upgrade to braintrust v0.28.0 or later and rotate credentials that may have been recorded. Upgrading prevents affected fields from being recorded in new traces, but does not remove credentials from traces already stored.

​
Frequently asked questions

​
Was this a supply chain attack?

No. This was an implementation bug in Braintrust-maintained LiteLLM instrumentation. We found no compromise of the braintrust PyPI package, its build or publishing process, LiteLLM, or Braintrust systems.

​
Which versions were affected?

The issue affected braintrust v0.2.0 to v0.27.x. It is fixed in braintrust v0.28.0 and later.

​
Which instrumentation entry points were affected?

The affected paths were:
  • wrap_litellm() beginning in braintrust==0.2.0.
  • patch_litellm() beginning in braintrust==0.3.5.
  • LiteLLM instrumentation through auto_instrument() beginning in braintrust==0.5.2.
An application may be affected when it used one of these entry points and passed credentials directly as keyword arguments to an instrumented LiteLLM call.

​
What credentials could have been recorded?

Confirmed examples include:
  • API keys.
  • Authorization and API-key headers.
  • Azure authentication tokens.
  • AWS access keys, secret keys, and session tokens.
  • Vertex AI credentials.
Other provider-specific secrets may also have been recorded because LiteLLM accepts arbitrary keyword arguments.

​
Were credentials loaded from environment variables affected?

Credentials obtained by LiteLLM solely through environment variables, global LiteLLM configuration, or a cloud provider’s default credential chain were not captured by this issue because they were not present in the instrumented call arguments.

​
Were credentials sent anywhere other than Braintrust?

The instrumentation included the values in Braintrust span metadata. Normal provider requests were still sent to the provider selected through LiteLLM. We found no evidence that the issue transmitted credentials to any additional third party.

​
How can I check for affected traces?

Follow Check for affected traces in the GitHub security advisory. The query identifies common credential fields without returning their values. Because LiteLLM supports arbitrary provider-specific keyword arguments, the absence of results does not rule out credentials passed through custom argument names.

​
What changed in the fixed version?

The patched release records only an allowlist of known-safe LiteLLM request parameters. Credential fields, headers, transport configuration, and unknown provider-specific arguments are omitted from new span metadata by default.

​
Does upgrading remove existing metadata?

No. Upgrading prevents affected fields from being recorded in new traces, but it does not modify traces already stored.

​
What should I do if I find an affected trace?

Rotate the credential as soon as possible. Then review project access and upgrade every affected application to braintrust v0.28.0 or later.

​
What can I do if I cannot upgrade immediately?

Follow the workarounds in the GitHub security advisory. They include using environment-based authentication, configuring braintrust.set_masking_function(), or disabling LiteLLM instrumentation until you can upgrade.