Poisoned LiteLLM Packages on PyPI May Have Leaked Secrets From 2,100 Organisations
CloudSEK says a 434,000-file dataset stolen during a 40-minute window in March traces back to two malicious releases of the popular AI gateway library.
Key points
- Two malicious versions of LiteLLM, a popular open-source tool that routes requests to AI models, sat on PyPI for roughly 40 minutes in March 2024 before being pulled.
- The tampered packages ran hidden code that scraped cloud keys, SSH keys, Kubernetes tokens and database passwords from any machine that installed them.
- Threat intelligence firm CloudSEK says it obtained the attackers' loot: about 434,000 files taken from victims during that short window.
- CloudSEK's analysis of the dataset maps possible exposure to more than 2,100 organisations worldwide.
- The intrusion shares tradecraft with an earlier supply-chain hit on Trivy, the open-source vulnerability scanner, suggesting the same operators.
A short window. A big blast radius.
For about 40 minutes in March, two booby-trapped releases of LiteLLM, a widely used Python library that lets developers route calls to many AI models through one interface, were live on PyPI, the main repository where Python developers fetch their code. Anyone who ran a routine install during that window pulled in code designed to rifle through their machine and exfiltrate anything valuable.
The haul was not small. CloudSEK, the threat intelligence firm that obtained the attackers' collection, counted roughly 434,000 files harvested from victim systems, with fingerprints inside the dataset pointing to more than 2,100 organisations that may have exposure, according to The Hacker News. We first reported this LiteLLM compromise on 7 August, when three hours of live malicious code was already enough to reach tens of thousands of companies.
What did the malicious code actually steal?
The injected code hunted for cloud provider access keys (credentials that let software authenticate to Amazon or Google cloud accounts), SSH keys used to log into servers remotely, Kubernetes tokens that control container fleets running production apps, and database credentials stored in configuration files. In a modern engineering shop these files sit in predictable places, which is exactly what the attackers counted on.
Once a key like that is out, the damage isn't confined to the laptop that ran the install. A live cloud key lets an attacker spin up infrastructure, read customer data, or plant a quiet backdoor for later.
Who is behind it?
CloudSEK links this operation to the earlier poisoning of Trivy, an open-source scanner many companies use to check their containers for vulnerabilities. The overlap is in tradecraft and infrastructure rather than a named group, so attribution sits at medium confidence at best. No public cluster name has been attached.
The motive looks financial and opportunistic, not espionage. Grab credentials, monetise access, move on.
The known timeline
| Date | Event |
|---|---|
| March 2024 | Two malicious LiteLLM versions published to PyPI |
| ~40 minutes later | Packages removed after detection |
| Earlier incident | Trivy supply-chain compromise with overlapping TTPs |
| November 2024 | CloudSEK publishes analysis mapping 2,100+ potentially affected organisations |
Should you worry if you use LiteLLM?
Assume exposure if you installed LiteLLM during that March window. Rotate anything the code could have reached: cloud access keys, SSH keys, Kubernetes service account tokens, and any API keys sitting in environment files on the affected build machine.
Check cloud audit logs for the days following install. Look for logins from unfamiliar locations or newly created access keys. Pin dependency versions and require review on any package bump that touches production. Don't treat "it was only up for 40 minutes" as comfort. Automated build pipelines pull fresh packages constantly, and 40 minutes is plenty.
Ordinary users of AI products built on LiteLLM don't need to take direct action. The risk lands on the companies that shipped code using the poisoned versions, and on customers whose data lived in those cloud accounts.
