The LiteLLM supply chain attack started with an unrevoked master key committed on May 27, 2026. On October 10 that key yielded owner-level GitHub access, and on October 21 the attacker published credential-stealing 1.107.0 to PyPI and Docker. Installers should rotate cloud, AI, and developer credentials.
Key Takeaways
- A May 27 master key in a public repo was never revoked.
- On October 10 the key yielded owner-level GitHub access.
- Backdoored LiteLLM 1.107.0 reached PyPI and Docker on October 21.
- Installers should rotate cloud, AI, and developer credentials.
How the LiteLLM Supply Chain Attack Got an Owner Token
Oliver Jensen and Mateo Wang said a configuration file committed to public repository LiteLLM-Labs/lite-harness “inadvertently contained the master key” to the LiteLLM Agent Platform. The error was identified quickly and the commit was force-pushed over. Key revocation still did not occur for the master key, according to LiteLLM’s attack-chain account.
On October 10, requests from 69.48.229.143 used the key on the Agent Platform API. At 21:27:10 UTC, a managed-agent listing returned the GitHub CLI OAuth token of one of two organization owners. The token was not scoped down and was not a service account.
LiteLLM said these CLI tokens are past two-factor authentication and are not subject to GitHub’s super-user reauthentication on sensitive organization actions. The platform was set up so self-hosted agents could open pull requests.
Stolen CI Tokens and a Relaxed Release Rule
The owner token was used the same night to take more credentials. At 22:11:45 UTC, branch ci-tmp-a351cc in BerriAI/litellm posted six secrets, including a second maintainer’s GH_TOKEN, to a webhook.site endpoint. Twenty-four seconds later, a run in BerriAI/litellm-auto exposed a third maintainer’s RELEASE_PLEASE_TOKEN. Both runs were deleted minutes later.
LiteLLM said the hash of GH_TOKEN matched the token that approved the release, and the other token hash matched the token that deleted the release runs. The hashes identified tokens, not the accounts behind them.
Socket, as reported by The Hacker News, recovered an October 12 round that added .github/workflows/cache.yml on branches deleted within minutes. Across the workflow runs, collection included GitHub tokens, a GitHub App signing key, and API keys for Linear, Together AI, Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian. LiteLLM said the October 12 secrets were not on the path to the poisoned artifacts.
On October 21, from 199.91.221.39, the attacker bypassed branch protection on private repository BerriAI/project-releaser and pointed builds at lookalike Berri-AI/litellm rather than BerriAI/litellm. A normal release needed an authorized engineer plus an account locked to a physical device in the office.
LiteLLM had relaxed that rule earlier in the week so any two engineers could trigger and approve a release, to allow more frequent releases and bugfix backports. One stolen token started the build and another approved it. Maintainers believe the separate tokens were meant to evade a noisy audit log.
What Backdoored 1.107.0 Did on PyPI
The Hacker News said Upwind researcher Lidor Machluf reported the attack at 12:06 UTC. Wiz’s incident analysis put ClickPy downloads at about 49,000 and named v1.106.2 the most recent safe release.
Poisoned container tags included v1.107.0, latest, main-latest, and main-stable. Wiz recorded Docker Hub and GHCR tag removal near 13:53 UTC; LiteLLM says its Docker images were removed by 14:20 UTC.
| Event | Figure | Source |
|---|---|---|
| Master key committed, not revoked | May 27, 2026 | LiteLLM |
| Owner token returned by API | Oct 10, 21:27:10 UTC | LiteLLM |
| 1.107.0 published | About 11:40 UTC, Oct 21 | LiteLLM |
| PyPI release frozen | 13:23 UTC, Oct 21 | LiteLLM |
| Malicious downloads (ClickPy) | About 49,000 | Wiz |
cook.pth, cook.py, and sitecustomize.py were placed in the site-packages root so they execute when Python starts. Wiz said the sitecustomize.py path runs only on Linux and macOS. A stealer collected browser, cloud, SSH, Git, package-registry, and AI-provider secrets, then posted them to attacker-controlled litellm.dev, registered on October 13.
A Unix-oriented backdoor was designed to fetch and run attacker-supplied code every hour. Wiz said the dead-drop domain file was never populated beyond initial test values, so a successful second-stage fetch was not established. The Microsoft Security Research team said “simply starting Python in an affected environment could activate the malicious code, even when LiteLLM itself was never imported.” It also warned that “removing only the application files could leave the malicious startup components behind.”
Cloud Abuse After the LiteLLM Theft
Wiz Research saw stolen AWS instance-role credentials from CI runners and Kubernetes nodes validated between 16:20 and 17:01 UTC, about 4.5 hours after exfiltration. The actor then listed Bedrock foundation models, a pattern Wiz called consistent with LLMjacking. A small number of environments also saw IAM roles, users, and access keys listed.
LiteLLM’s first suspicion, tokens stolen from internal gateway logs, did not hold. The owner token was in the Agent Platform response. The company locked public registries, removed every GitHub member except one temporary owner, and began revoking tokens on internal systems and vendor platforms.
Anyone who installed or ran 1.107.0 should treat that host as exposed. Work through these checks:
- Remove 1.107.0 and confirm cook.pth, cook.py, and sitecustomize.py are gone from site-packages.
- Rotate cloud, AI, Git, SSH, and package-registry credentials used on that host.
- Treat LiteLLM proxy provider keys as exposed if that database was reachable.
- Review October 21 AWS logs for unexpected identity checks and Bedrock model listings.
