The latest LiteLLM fallout matters because it is no longer just a package-security anecdote. CloudSEK says the campaign may map to exposure across more than 2,500 organizations, based on a dataset of roughly 434,000 captured files tied to the broader TeamPCP / Trivy supply-chain compromise.
That does not mean 2,500 confirmed victims. It does mean a lot of teams may still be underestimating how long-lived the credential risk can be after a short-lived malicious package event.
What Changed
The malicious LiteLLM versions were 1.82.7 and 1.82.8, published to PyPI on March 24 and available for roughly 40 minutes before removal. The payload was designed to steal environment variables, cloud credentials, SSH keys, Kubernetes tokens, database passwords, and model-provider secrets, including items like OPENAI_API_KEY and ANTHROPIC_API_KEY.
Stay Current on Cyber Policy and Guidance
Track new CISA actions, regulations, guidance, and risk trends in a quick daily format.
Weekday mornings. Built from 100+ trusted cybersecurity sources.
A key detail makes this more dangerous than a normal package bug: version 1.82.8 included a .pth file that Python executes at interpreter startup. That means code could run even if no application explicitly imported LiteLLM, as long as the package landed in the environment.
The campaign also appears tied to the earlier Trivy compromise. Public reporting says exposed credentials were later used to publish the malicious LiteLLM versions, and the broader ecosystem incident is tracked as CVE-2026-33634, which CISA added to the KEV catalog in March.
Why CyberExperts Flagged It
The most important shift here is the triage model. This is not only a “do we use LiteLLM?” question. It is a where could this have been installed directly or transitively, and what secrets were reachable at that moment? question.
That matters for AI-platform teams, but it also matters for CI/CD, cloud, and application owners who may have no idea a transitive dependency briefly introduced a secret-harvesting payload into their environment.
What Teams Should Do Next
- Check whether LiteLLM 1.82.7 or 1.82.8 was installed during the March 24 exposure window, including through transitive dependencies or agent/orchestration tooling.
- Rotate any cloud credentials, SSH keys, publishing tokens, Kubernetes secrets, database credentials, and model-provider API keys that were accessible from those environments.
- Search GitHub organizations for
tpcp-docsordocs-tpcprepository names, which the FBI has listed as campaign indicators. - Treat this as a credential-exposure problem, not just a package-removal task. If secrets were reachable, removal without rotation is not enough.
- Review where your engineering workflow still depends on long-lived secrets and move those paths toward shorter-lived or ephemeral credentials where possible.
Source context: CyberExperts is using The Hacker News as the primary reference for this update, with additional campaign context cited there from CloudSEK, Aqua, Unit 42, and the FBI advisory.
See this item in The 5-Minute Cyber Brief
