The LiteLLM Supply Chain Attack: What Every AI Ops Team Should Fix This Weekend
A master key committed to a public GitHub repo on May 27 sat unrevoked for nearly five months. On October 21, that key became a supply chain attack that put 49,000 LiteLLM downloads in the hands of a credential stealer and a remote access trojan.
If you run AI pipelines with LiteLLM, open-source LLM proxies, or agent tooling in production, this post is your weekend audit checklist. The incident is contained. The credentials that got out are not your concern. Your exposure to the same class of error is.
What happened :
On October 21, 2026, LiteLLM's release pipeline published litellm==1.107.0 to PyPI and to its container registries. The package contained compiled malware. Seven PyPI wheels went live at 11:39 UTC. PyPI pulled them at 13:23 UTC. The Docker images stayed up until 14:20 UTC.
According to SecurityWeek and LiteLLM's own postmortem, the malicious package was downloaded roughly 49,000 times during that window.
The malware, which LiteLLM's security team and Wiz researchers analyzed in detail, targeted:
- Cloud credentials: AWS, Azure, GCP, Kubernetes, Docker
- AI API keys: OpenAI, Anthropic, Cohere, and any LLM provider keys in environment variables or config files
- Developer credentials: GitHub, npm, PyPI, CI/CD secrets,
.envfiles - Browser data: saved logins, cookies, session tokens from Chrome, Firefox, Edge, Safari
- SSH private keys, GPG keys, shell history
- GitHub Copilot authentication tokens :
The payload also dropped a persistent loader (sitecustomize.py) that checked an external server every hour and executed whatever Python it was pointed at. Microsoft's security blog noted that this ran on every Python start, regardless of whether the application ever imported LiteLLM. Running pip to investigate an affected install also triggered the stealer.
Wiz researchers found that credential exploitation began roughly four and a half hours after exfiltration. AWS instance role credentials harvested from CI runners and Kubernetes nodes were validated across multiple environments.
How a five-month-old exposed key became a pipeline takeover :
The attack chain is textbook. A version of it will happen again somewhere else.
May 27, 2026. A configuration file is committed to the public LiteLLM-Labs/lite-harness repository. It contains the master key to an internal LiteLLM Agent Platform deployment. The commit is force-pushed over quickly. The key is flagged for revocation. Revocation does not happen.
The Agent Platform was an experimental tool for self-hosted agents to file GitHub PRs. It was configured with a GitHub CLI OAuth token associated with an organization owner's account. Not a service account, not scoped down.
October 10, 2026. An attacker calls the Agent Platform API from 69.48.229.143 using the master key. A single API call to GET /api/v1/managed_agents/agents?limit=100 returns the owner's GitHub CLI token in the response. The attacker now has owner-level GitHub access.
From there, the attacker uses legitimate CI workflows to post additional secrets to a webhook.site endpoint, harvesting tokens for two more maintainers. Then deletes the workflow runs to cover the tracks.
October 21, 2026. The attacker uses the owner's token to override branch protection, redirect the release pipeline to a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), uses a second maintainer token to approve the production gate, and publishes v1.107.0. The third token deletes the pipeline run records. The release looks clean in the audit log until forensic investigation.
The full timeline is documented in LiteLLM's attack chain postmortem at docs.litellm.ai.
The gap that made it possible
The attacker did not find a zero-day. They found a credential that was never revoked, in a service that was misconfigured, connected to an account that had too much access.
The specific failure was this: a key was identified as exposed, flagged for revocation, and then not revoked. That is not a tools problem or a process maturity problem. It is a gap between identifying a risk and closing it, which happens on teams that move fast and treat internal tooling as lower priority than production.
For AI ops teams, this gap is wider than it looks. Most teams that run LLM pipelines have credentials scattered across environment variables, .env files, proxy config files, CI/CD secrets, and developer workstations. Many of those credentials have broad permissions because they were set up quickly to get something working and never tightened. Many have never been rotated.
What to check this weekend :
If you run LiteLLM or any open-source LLM proxy in production, run through this audit before Monday.
1. Check what version you are running.
pip show litellm
If you see 1.107.0, stop. Do not run Python in that environment. Isolate the system, rebuild from a clean backup, and rotate every credential the machine could access. The recommended clean version is 1.106.2.
2. Look for the three malicious files.
cook.pth
cook.py
sitecustomize.py
These land in the environment's Python library directory. If they are there, treat the environment as fully compromised.
3. Audit who has owner-level GitHub access on your org.
Owner-level GitHub tokens are post-2FA and bypass GitHub's "super-user" re-authentication for sensitive actions. If any of those tokens live in a CI/CD secret, in a config file, or in an agent that calls external APIs, scope them down or replace them with scoped service tokens.
4. Check your .env files and config files for AI API keys.
Search your repos:
grep -r "OPENAI_API_KEY\|ANTHROPIC_API_KEY\|sk-" . --include="*.env" --include="*.json" --include="*.yaml"
If any of these are committed to a repository, even a private one, rotate them immediately.
5. Audit open-source dependencies in your AI tooling.
LiteLLM has 92 million monthly PyPI downloads (per LiteLLM, October 2026). It is infrastructure for a large portion of production AI pipelines. Check whether your team has a process for verifying releases before updating. If not, add one. A simple pip-audit run and checking release commit signatures costs less than an incident.
6. Revoke and rotate anything that was exposed.
If your systems ran litellm==1.107.0 during the window, assume all credentials those systems could access are compromised and rotate them. The Wiz postmortem notes that exploitation started four and a half hours after exfiltration.
The broader lesson :
AI ops tooling is now a primary attack surface. LiteLLM has 61,800 GitHub stars and runs in production at NVIDIA, Netflix, AT&T, and Okta, according to BleepingComputer. A package this embedded in AI infrastructure is worth more to an attacker than most application targets. The credentials it touches, AWS IAM roles, Anthropic keys, GitHub tokens, enable lateral movement across an entire organization.
This attack was contained in about two hours because LiteLLM's team moved fast and multiple security researchers detected the malicious release within minutes of it going live, according to BleepingComputer. Not every supply chain incident gets caught that quickly.
The root cause was a credential hygiene failure most teams share in some form: credentials with more access than needed, sitting in places that were never meant to be permanent, never rotated. Fixing that does not require a new tool. It requires treating AI pipeline credentials the same way you treat production database credentials.
If you want a team that audits and hardens your AI ops stack before an incident does it for you, talk to us.
Sources:
Frequently Asked Questions
Only litellm==1.107.0 published to PyPI on October 21, 2026 contained malicious code. The Docker container images for the same version were also compromised. Version 1.106.2 and earlier are clean. If you see 1.107.0 in your environment, isolate the system before running any Python commands.
The malware targeted AI API keys (OpenAI, Anthropic, Cohere), cloud credentials (AWS, Azure, GCP, Kubernetes, Docker), developer tokens (GitHub, npm, PyPI, CI/CD secrets), browser saved passwords and session cookies, SSH private keys, GPG keys, shell history, and GitHub Copilot authentication tokens.
A configuration file committed to a public GitHub repository on May 27, 2026 exposed a master key for an internal LiteLLM Agent Platform. The key was flagged for revocation but never revoked. On October 10 an attacker used it to extract a GitHub owner-level token from the API response, then used that token to hijack the release pipeline.
Treat the environment as fully compromised. Do not run Python in that environment to investigate. Isolate the system, rebuild from a clean backup, and immediately rotate every credential the machine could access including cloud IAM credentials, LLM API keys, GitHub tokens, and any secrets stored in environment variables or config files.
Run pip-audit on every new release before upgrading in production. Check release commit signatures. Restrict AI API keys and cloud credentials to the minimum permissions required. Never commit credentials to repositories, even private ones. Treat open-source AI infrastructure credentials with the same rotation discipline as production database credentials.
Yes. PyPI pulled the malicious wheels at 13:23 UTC, about two hours after publication. Docker images were removed by 14:20 UTC. LiteLLM's team and security researchers detected the malicious release quickly. However, 49,000 downloads occurred during the window, and Wiz researchers found credential exploitation began approximately four and a half hours after initial exfiltration.