On 24 March 2026 (LiteLLM security notice, last updated that day, 2:00 PM ET, still marked active investigation), LiteLLM reports a suspected supply-chain compromise on PyPI. They name litellm==1.82.7 and litellm==1.82.8 as impacted releases; both are removed from PyPI. For 1.82.7 they report malicious code in the AI Gateway proxy_server.py. For 1.82.8 they report the same plus a litellm_init.pth file they list among IoCs.
They describe malware consistent with stealing secrets from the machine (for example environment variables, SSH keys, cloud and Kubernetes credentials, database passwords) and exfiltration by POST to models.litellm.cloud, which they state is not an official LiteLLM or BerriAI domain. They say they believe the compromise may tie to Trivy in their CI scanning workflow and to the broader Trivy supply chain situation, and that uploads may have bypassed normal CI.
What LiteLLM shared
The affected PyPI releases they identify are litellm==1.82.7 and litellm==1.82.8. Both were removed from the public index, so pip will not serve them from PyPI going forward. Copies can still exist in old virtualenvs, image layers, caches, or mirrors, so verification still matters.
They describe malware consistent with credential theft (environment variables, SSH keys, cloud provider credentials, Kubernetes tokens, database passwords) and exfiltration involving a host they state is not under their control (models.litellm.cloud). They also list litellm_init.pth as an on-disk indicator for the 1.82.8 line.
Helpful specifics from their post for your runbook:
- Install window they call out: 24 March 2026, roughly 10:39 UTC to 16:00 UTC, for
pip-based installs. - Transitive exposure: they note risk through AI agent frameworks, MCP servers, and orchestration tools, not only direct
pip install litellm. - Paths they say were not affected: LiteLLM Cloud customers; users of the official Gateway Docker image (
ghcr.io/berriai/litellm) because that path pins dependencies rather than pulling those PyPI releases; installs from GitHub source; and anyone who stayed on v1.82.6 or earlier without upgrading inside the affected window. - Early root-cause context: they link their findings to Trivy in CI scanning and to the broader Trivy supply chain situation (background from Aquasec). They report that the malicious upload may have bypassed their normal release checks.
They also describe steps already taken (including removing the malicious packages, rotating maintainer access, pausing releases pending a broader supply-chain review, and bringing in Mandiant for forensics), plus rotation guidance, IoCs, and example searches for litellm_init.pth.
Transitive installs and busy CI runners
Incidents like this rarely stay inside one package label. Dependencies can show up through agents, templates, or shared runners you did not think to grep. Builds also sit close to secrets. Bad releases can circulate for hours or days before the story is public and everyone knows what to grep for. Pins, mirrors, and process still carry the load. Honeytokens in pipelines add a parallel defense: if malicious code touches those credentials, you can get an immediate alert at the moment of misuse, not only after the next headline or tarball warning.
How can you detect these attacks?
Honeytokens are a detection solution: credentials that are provisioned for monitoring, not for production work. They are real enough to authenticate against the same services your automation already uses, so use of the token is the signal. Token types and placement (repo, pipeline, account, registry, or elsewhere) follow your threat model. When something triggers one, you get an alert. They complement patching and least privilege; they do not replace them.
While you respond
- Keep LiteLLM’s update open for versions, timelines, IoCs, and rotation advice.
- Scan CI, shared runners, dev images, and caches, not only production clusters.
- Continue fundamentals: pins where you can, least privilege, fewer long-lived secrets in build contexts.
- Honeytokens: treat them as part of normal pipeline defense, not a last resort. They fire when instrumented credentials are used, which can surface abuse early while broader detection and vendor timelines are still catching up.
Tropico Security builds software to run honeytoken programs: support for the token types you need, placed where you want them (CI and elsewhere). If you want to compare notes or see how we handle that, we are easy to reach.
