On March 24, 2026, malicious LiteLLM versions 1.82.7 and 1.82.8 were published to PyPI and later removed. PyPI said anyone who installed and ran the project should assume credentials in that environment may be exposed and should revoke or rotate them. Check your lock files, environments and CI logs for those versions.
What do the sources agree on?
PureAI's March 25, 2026 report says LiteLLM 1.82.7 and 1.82.8 were briefly published to PyPI and then removed. The malicious code was designed to harvest environment variables, SSH keys and cloud credentials for AWS, Google Cloud and Azure, and also targeted Kubernetes configuration, CI/CD secrets, database credentials and cryptocurrency wallets. A security firm reportedly found tooling for Kubernetes lateral movement and a persistent backdoor.
Projects could be affected through transitive dependencies. Installing another package that pulled in LiteLLM was enough.
How did the compromise happen?
Per the same report, Krrish Dholakia, CEO of Berri AI, which maintains LiteLLM, said the compromise appeared to stem from the project's use of an open source security scanner, in its CI/CD pipeline. Researchers have linked it to a group called TeamPCP.
This is the chain to take in: a tool inside the pipeline held credentials, those credentials were stolen, and the thief published as the project. It is reported by the maintainer and researchers, and details may be refined by later write-ups.
Where do reports differ?
How long the bad versions were live. One report says less than an hour, citing a public post. Other reports, found in search results but not independently confirmed here, give windows of several hours and different quarantine times. Treat the duration as uncertain and use your own logs to decide whether you installed during the day of March 24.
Also unclear from what we fetched: the precise mechanism by which each version ran its payload. Some secondary reports say one version used a startup hook file, but we did not confirm this from a primary source, so check the maintainers' and PyPI's own notices.
What should you check?
- Search lock files, requirements files, container images and CI caches for litellm 1.82.7 or 1.82.8.
- Check build logs for installs on March 24, 2026, including installs that happened as a transitive dependency.
- If either version was installed and run, rotate everything that environment could read: cloud keys, SSH keys, API tokens, Kubernetes credentials and database passwords.
- Rebuild affected hosts and images from a clean state rather than only upgrading.
- Review cloud audit logs for activity from the exposed credentials.
- Pin to a version published before the incident, or to a later release that the maintainers confirm is clean, and verify hashes.
A constructed example
A data team runs a nightly job in a container that installs dependencies without a lock file. The job pulled the newest version of a package that depends on LiteLLM. A search of the image registry shows one image built on March 24 with the bad version. The team rotates the cloud key that the job used, finds no unusual API calls in the audit log, and moves the job to a locked, hash-checked install.
What do you change afterward?
Lock and hash your installs. Keep CI secrets out of jobs that run third-party tools, and issue short-lived credentials per run. Limit which jobs can publish. And keep an SBOM per build so the next question, "did we ship this version," takes minutes.
Safeguard can generate SBOMs and scan dependencies across your repositories, which answers "where do we use this package and which version." It cannot rotate your credentials for you.
What should you not conclude?
Do not conclude that LiteLLM or any scanner is untrustworthy today based on one incident. The reports describe specific versions and a specific window. Do not skip rotation because logs look clean either: the payload was designed to read credentials quietly. Rotate first, investigate second, and keep evidence for later review.
Quick check
Which LiteLLM versions were affected?
1.82.7 and 1.82.8, according to reporting on the March 24, 2026 incident.
I upgraded after the incident. Am I safe?
Only if the bad versions never ran in your environment. If they did, rotate credentials and rebuild, since upgrading does not undo what the payload read.
Sources
Last reviewed: 18 October 2026.
