LiteLLM 1.82.7 and 1.82.8 were on PyPI on 24 March 2026 from 10:39 UTC, for about 40 minutes, before they were pulled. The project advises treating any install up to 16:00 UTC that day as potentially compromised.
Forty minutes. That is the whole exposure window, and it is more than enough, because the packages were not waiting for anyone to run them.
The payload ran before your code did
The releases shipped a file named litellm_init.pth. A .pth file in site-packages executes at Python interpreter startup — not on import of the package, not on any call into it. Installing it and then running anything at all in that environment was sufficient.
What it collected:
- Environment variables, including
OPENAI_API_KEYandANTHROPIC_API_KEY - SSH keys
- Cloud credentials
- Kubernetes tokens
- Database passwords
Encrypted, then sent to models.litellm[.]cloud — a domain chosen to survive a glance at egress logs.
How the attacker still had the token
This is part of the TeamPCP campaign, tracked by Google as UNC6780, and the chain back is the useful part.
| When | What |
|---|---|
| 19 March 2026 | Trivy scanner compromised |
| — | Credentials rotated — incompletely |
| 24 March 2026 | A surviving PyPI publishing token is used to push poisoned LiteLLM releases |
The attacker did not compromise LiteLLM. They compromised something else, kept a credential through the cleanup, and used it a week later against a different project.
That is the failure mode worth carrying out of this. An incomplete rotation is not a partial fix; it is no fix, on a delay. We made the same point about Mozilla revoking a signing key with no evidence of misuse — once a credential's secrecy is unprovable, the only safe assumption is that it is gone.
CVE-2026-33634 was assigned and added to CISA's KEV catalog on 26 March 2026.
The number everyone is quoting, and what it means
CloudSEK obtained roughly 434,000 captured files from the campaign and published a searchable dataset mapping possible exposure across more than 2,500 organisations — names including NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens and X Corp.
Read that carefully, because the framing matters and most coverage drops it.
This is captured loot and log files, not confirmed victim accounts. The 434,000 figure counts individual exfiltration events, not unique pipelines — one badly-configured CI job running hourly contributes hundreds of them.
CloudSEK's method: two independent checks, CI identity variables and a separate ownership derivation from the captured logs. Where they disagree, the report is withheld, and the lower confidence level sets the final classification.
That is more rigour than most exposure datasets carry, and it still does not convert "your name is in the data" into "you were breached."
Where it is confirmed
Three organisations have said something concrete:
- Checkmarx — unauthorised GitHub repository access, enabling malicious artifact publication
- Mercor — contained unauthorised activity after exposure to the poisoned versions
- CERT-EU — assessed with high confidence that a European Commission AWS account was compromised, with roughly 91.7 GB of compressed data exfiltrated
The CERT-EU figure is the one that establishes this was not a smash-and-grab of a few API keys.
The FBI's point about timing
Advisory FLASH-20260702-01 warns that credentials harvested in this campaign will likely be weaponised long after the initial compromise, and recommends rotating CI/CD secrets and cloud credentials.
That is the reason this is a story in August about something that happened in March. Stolen credentials do not expire on a news cycle. An organisation that checked its logs in March, found nothing, and moved on is exactly the organisation this advisory is addressed to.
What to do
- Rotate CI/CD and cloud credentials if you installed LiteLLM on 24 March, even if you saw no follow-on activity. Especially then.
- Search for
models.litellm[.]cloudin DNS and proxy logs going back to March. - Audit
.pthfiles in your site-packages. Most environments have a handful and you should be able to account for every one. - Check whether your March rotation was complete. Publishing tokens, deploy keys and machine accounts are the ones that get missed, because no human notices them failing.
- Treat the CloudSEK dataset as a prompt, not a verdict. Your name appearing there means look; it does not mean you were breached.
The structural lesson is the one behind every entry in this category, from the npm dropper that flooded the registry to CI secrets reachable from coding agents: the blast radius of a package is the blast radius of the environment it installs into, and for AI tooling that environment holds every key you own.
