LiteLLM says leaked agent tokens in gateway logs led to its compromised release

LiteLLM's maintainers say a malicious litellm==1.107.0 was live on PyPI for about two hours, from 11:39 to 13:23 UTC, and that four Docker tags (v1.107.0, latest, main-latest, main-stable) pointed at a compromised image until 14:20 UTC. They say the official source tag did not contain the malware; the artifacts were built from an attacker-controlled repository. Their advice is to pin to 1.106.2 or earlier, and to rotate the instance role, every provider key in the proxy database, the master and virtual keys, and the database password on any host that ran the bad version.

The attack chain is the new part. LiteLLM says the attacker held GitHub CLI credentials for three developers, one of them an organization owner. It says the attacker used that token to disable branch protections, force-push a change that pointed the release workflow at a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), and run it. Two days earlier the team had temporarily widened release permissions so two engineers could publish bugfix backports. The post says a third developer's credentials were then used to delete the workflow records.

On where the tokens came from, the post says LiteLLM has seen specific situations in which Claude Code embeds a user's GitHub CLI OAuth token in a response body. It says that where response bodies are logged, the tokens can land in LiteLLM logs, and it believes the attacker read them from an internal LiteLLM deployment that was exposed to the internet. It has not confirmed how the attacker got into that deployment and suspects a recently patched vulnerability. This is LiteLLM's account of its own incident. We have not seen a response from Anthropic, and the post does not say how often the Claude Code behavior occurs.

Why it matters: If LiteLLM's account holds, logs from any gateway that records agent response bodies can contain the credentials those agents carry, so they need the same access controls and retention limits as a secrets store. It also shows how a short-lived widening of release permissions combined with one organization-owner token to defeat controls the team had hardened after its March incident.