LiteLLM: from a forgotten Git secret to a signed malicious release

Compromised artifacts published: 21 October 2026. Analysis written on 4 November 2026. LiteLLM’s canonical incident report reconstructs a multi-month compromise: an administrative key committed to a public Git repository in May, still valid in October, led to an organization owner’s GitHub token and ultimately to a release built from an attacker-controlled lookalike repository. PyPI package litellm==1.107.0 and several Docker tags carried malware. The publication pipeline signed those artifacts legitimately; its source selection had been subverted.

The credential chain

On 27 May, a configuration file containing an administrative key to an experimental LiteLLM Agent Platform was committed publicly. The file was deleted in a later commit, but the old commit remained in history and the key was not revoked. On 10 October, an attacker used it to call the platform API. A managed-agents response contained the GitHub CLI OAuth token of a LiteLLM organization owner. This token had broad owner privileges, beyond the repository-scoped capability that the platform actually needed. (LiteLLM timeline)

Using that token, the attacker ran throwaway GitHub workflows that posted CI secrets to an external endpoint. They obtained tokens belonging to two other maintainers. This illustrates an important distinction: a user may be unable to read a repository secret through the UI while still being able to run a workflow that receives it. The incident report documents the API calls, branches and workflow runs, including later deletion of some run records.

On 21 October, the attacker changed the private release workflow to accept a source_owner input. A push under a maintainer token was rejected by branch protection; a push under the organization owner’s token succeeded. The altered workflow built from Berri-AI/litellm, visually close to the real BerriAI/litellm. Two compromised identities started and approved the release. The official GitHub v1.107.0 source tag did not contain the malware because the published wheels and images came from the substituted source. A signature could verify perfectly while the artifact’s provenance was wrong.

What execution meant for a consumer

LiteLLM’s affected-artifact notice says the compiled malware stole credentials and loaded remote-execution tools. cook.pth and sitecustomize.py were filesystem indicators. Python may process those files at interpreter startup, so even running pip in a compromised environment can execute the malware again. The PyPI wheels were live from about 11:40 to 13:23 UTC. Docker v1.107.0, latest, main-latest and main-stable were affected from roughly 11:46 to 14:20 UTC. Older explicit releases and the private Enterprise registry were reported unaffected.

The strongest detection combines package or image digest history, deployed version, CI build provenance and host evidence. A tag that points to a clean image today may have pointed to a poisoned digest during the incident. The first public report appeared in a GitHub issue at 12:06 UTC. A defender could also have found the old committed secret, the unrevoked key, owner-level token use, branch-protection override and divergence between qualified source and built source.

If a poisoned artifact ran with outbound network access, LiteLLM says to assume accessible secrets were exfiltrated. Rebuild affected images and Python environments from trusted sources, rotate model-provider keys, IAM roles, proxy master and virtual keys, database passwords and any other secrets reachable from the host. Uninstalling a package does not invalidate a copied credential. (Official response steps)

The failure was a chain: deletion without revocation, excessive scope on an agent platform token, owner override of release protections and a build whose source owner could change. Artifact signing remained intact, which is why signature verification alone would miss this attack.

The review of tokens and deployment permissions connects with the Binance attack analysis, although its access chain differs. For an agent platform, our guide to multi-agent contracts and orchestration explains how to bound tools, permissions and approval requirements alongside dependency verification.

Primary sources: LiteLLM root cause report, LiteLLM artifact and response notice.