LiteLLM PyPI compromise: rotate every key it touched

The LiteLLM PyPI compromise was a 40-minute window in March. The bill is still arriving. New threat-intel analysis published this week suggests the blast radius was far wider than the download count implied — and the payload was written specifically to grab AI provider keys. If you run an AI gateway, this is your Tuesday.

What actually happened

Two malicious versions of the litellm package, 1.82.7 and 1.82.8, went live on PyPI on March 24, 2026 at 10:39 UTC and stayed up for roughly 40 minutes before PyPI quarantined them. The LiteLLM project's own incident thread confirms the maintainer's PyPI account was hijacked and the packages were pushed directly to PyPI, bypassing the project's GitHub CI/CD entirely — GitHub releases only went to v1.82.6.dev1. The project tells users to treat any install that day up to 16:00 UTC as suspect.

The payload dropped a file called litellm_init.pth into site-packages, which Python executes at interpreter startup — so it ran on import, not on install. Per the project and Unit 42's analysis reported by The Hacker News, it collected SSH keys, AWS/GCP/Azure credentials, Kubernetes secrets, database passwords, CI/CD tokens, and environment variables — explicitly including OPENAI_API_KEY and ANTHROPIC_API_KEY. Data was encrypted and shipped to an attacker-registered domain.

The new number: CloudSEK's review of roughly 434,000 captured files and log entries points to more than 2,100 organizations with potential exposure. Treat that as an upper-bound estimate derived from attacker-side loot, not a confirmed victim list — CloudSEK says so itself.

The entry path is the part worth internalizing. Nobody attacked LiteLLM. The actor — tracked as TeamPCP, and as UNC6780 by Google — had already compromised Trivy, the container scanner. LiteLLM's CI installed the poisoned Trivy automatically, which handed over the PyPI publishing credentials. A security tool was the delivery vehicle. Docker image users were unaffected because their dependencies were pinned.

Why supply chain compromise matters for your AI stack

An AI gateway is the single worst place in your infrastructure to lose a dependency, because it is the one process that legitimately holds every model key you own. That is its job. When it gets backdoored, the attacker does not need to escalate — they just read the environment.

Three things to do, in order:

1. Grep for it. Look for litellm_init.pth in every site-packages directory, every container image built in that window, and every CI cache. Import-time payloads survive in layers you stopped thinking about.
2. Rotate on blast radius, not on evidence. If a host ran the bad version, rotate everything that host could reach — model keys, cloud creds, CI tokens, DB passwords. Absence of alerts is not absence of theft.
3. Pin and verify. Exact version pins plus hash verification would have made this a non-event, the way it was for the Docker users. Same lesson as npm 12 turning off install scripts — the default is the vulnerability.

And the structural one: short-lived credentials. A stolen OIDC-issued token that expired in March is a footnote. A long-lived sk- key is still working today.

Sources: LiteLLM incident thread on GitHub, The Hacker News.