If your team uses Python for anything AI related, there is a good chance LiteLLM is somewhere in your stack. It is a popular gateway that lets one codebase talk to many model providers. On October 21, a poisoned release of it spent about two hours on PyPI and Docker registries. This post explains what happened, who needs to act, and the habits that make the next incident a smaller one.
My recent posts covered PHP2Shell, the record Patch Tuesday, AI coding agents and the weekly web stack patches. This one is about a different kind of risk: the packages we install without a second thought.
What happened
The project's release pipeline was compromised early on October 21, and a version labelled 1.107.0 was published to PyPI, Docker Hub and the GitHub container registry. LiteLLM says all earlier versions are safe, the bad releases have been pulled, and customers of its private enterprise registry were not affected.
One detail is worth knowing. The official 1.107.0 source tag on GitHub did not contain the malicious files. The packages were built from a lookalike repository, Berri-AI/litellm, which is one hyphen away from the real BerriAI/litellm. That is why reading the public source would not have caught it.
Am I affected? The exact windows
According to LiteLLM's incident report, all times UTC on October 21:
- PyPI, litellm 1.107.0 (all seven wheels): live from 11:39 to 13:23.
- Docker Hub tags v1.107.0, latest, main-latest and main-stable: pointed at the bad image from 11:46 to 14:20.
- GitHub container registry tags: unavailable by 13:51.
You are in the affected group if you ran pip install on an unpinned LiteLLM, or pulled one of those image tags, inside those windows. If you were pinned to an earlier version, you were not.
What the malicious code did
Researchers at Socket describe malicious files placed in Python startup locations, which means the code runs whenever Python starts in that environment, even if your application never imports LiteLLM. The reported targets included cloud credentials for AWS, Azure, Google Cloud, Kubernetes and Docker, plus Git credentials, SSH and GPG keys, browser data, and authentication files for several AI tools. The collected data was encrypted and sent to an outside address. A second component periodically checked for more code to run.
Wiz reported that about four and a half hours after the data left victim systems, the attacker started testing stolen AWS credentials, including whether they could reach AI models on Amazon Bedrock. So the keys were tried quickly, and rotation is the part that cannot wait.
How the attackers got in
LiteLLM first suspected one route, then corrected itself after finishing its investigation, and I am using the corrected account. In late May, a configuration file containing the master key for an experimental internal service was committed to a public repository. The commit was replaced, but that key was never revoked. On October 10 the attacker used it to read a GitHub token belonging to an organization owner. With that, they used the project's own CI workflows to collect tokens from two maintainers. On October 21 they pointed the release workflow at the lookalike repository, approved the release with a stolen token and deleted the workflow records.
The lesson is a kind one for every team: an exposed key stays dangerous until it is rotated, and broad personal tokens in automation make a small leak much bigger. LiteLLM has said it is rotating every token across its systems and plans to share process changes.
If you ran 1.107.0
Please follow LiteLLM's guidance, and do it from a shell rather than by running Python:
- Do not start with pip install. Any Python start in the affected environment runs the startup files again, and that includes pip.
- Delete cook.pth, cook.py and sitecustomize.py (and their cached .pyc files) from every affected site-packages folder, and stop the background Python process that holds /tmp/remote_code_loader.lock.
- Reinstall pinned to litellm 1.106.2, or better, rebuild images and virtual environments from scratch.
- Assume the data left the machine if it had internet access. Finding the marker files confirms exposure, but not finding them proves nothing.
- Rotate everything the host could reach: cloud roles, every provider key stored in the LiteLLM proxy database, the master and virtual keys, the database password, and any secret in a process environment.
- In AWS CloudTrail, look for GetCallerIdentity calls from the instance role around install time, then for use of its credentials from outside your network.
Habits that shrink the blast radius
- Pin exact versions in a lockfile, and use hash checking where your tooling supports it.
- Pin container images by digest, not by tags such as latest. A tag is only as safe as the last push to it.
- Give CI and automation scoped tokens from service accounts instead of a person's own login.
- Rotate keys the moment they appear anywhere public, even briefly.
- Keep secrets out of long-lived environment variables where you can, so one compromised process sees less.
What this shows
Trusted channels can carry bad code. The release came through the same registries teams use every day. AI gateways collect many keys in one place, which makes them attractive. And speed helped here: a community member opened a public issue within about half an hour of publication, and the registries removed the files within hours. Good habits make the difference between a close call and a clean-up.
A short checklist for this week
- Search your projects and images for litellm 1.107.0.
- Confirm every LiteLLM install is pinned to 1.106.2 or an earlier explicit version.
- If anything ran 1.107.0, isolate it, clean it and rotate its credentials.
- Switch floating image tags to digests.
- Review which tokens your CI uses and trim their scope.
Calm, steady steps now save a long weekend later. If you want help reviewing a WordPress, Python or hosting setup, you can find me at expertwebdeveloper.in and read more security notes at growsmartwithai.com.
This post is also available on expertwebdeveloper.in, growsmartwithai.com, Medium, Substack and LinkedIn.
Sources: LiteLLM incident report · LiteLLM attack chain write-up · Help Net Security
Top comments (0)