LiteLLM 1.107.0 was compromised: credential stealer on PyPI and Docker, pin 1.106.2

What happened

On October 21, 2026, litellm 1.107.0 was published to PyPI and to Docker Hub and GHCR. It was reported in a GitHub issue by the Upwind security research team, and LiteLLM's maintainers confirmed it in an incident post. The official v1.107.0 source tag is clean; the release artifacts were built from a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm.

According to the report, each affected wheel adds files that run on every Python start in that environment. One collects credentials such as cloud keys, SSH keys, browser passwords, environment variables and AI tool configs, and, if DATABASE_URL is set, the provider keys stored in the LiteLLM proxy database. Another starts a background loader that can fetch and run remote code.

Who is affected and when

LiteLLM says the PyPI package was live from 11:39 to 13:23 UTC, and the Docker images v1.107.0, latest, main-latest and main-stable pointed to the infected image from 11:46 UTC until 14:20 UTC on Docker Hub and 13:51 UTC on GHCR. You are affected if you installed an unpinned version in that window or started one of those images.

Enterprise customers using LiteLLM's private registry were not affected. On October 22 PyPI listed 1.106.2 as the latest version and 1.107.0 was no longer available. Regular releases are paused while the investigation continues.

What to do now

Check with pip show litellm and look for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py in site-packages. Finding one confirms exposure; not finding one does not prove the environment is clean.

If affected, do not start with pip install, because any Python start runs the payload again. Delete the injected files from the shell, stop the detached Python process, then reinstall litellm==1.106.2, ideally by rebuilding the environment or image. Assume the data was exfiltrated if the host had internet access, and rotate the instance role, every provider key in the proxy database, the master and virtual keys, the database password and any secret in the host's environment.

How it happened and open questions

The maintainers say the attacker used stolen GitHub CLI OAuth tokens from three engineers, including an organization owner, to change the release workflow and point it at the lookalike repository. They believe the tokens were taken from logs of an internal LiteLLM deployment exposed to the internet, and report that Claude Code can, in specific situations, embed a GitHub CLI token in a response body that may then be logged. The maintainers say they are still working on confirming these findings. We found no public statement from Anthropic about the Claude Code claim as of October 22, and a question in the GitHub issue about how the token ends up in a response had not been answered by the maintainers when we checked on October 22 at 13:00 UTC.

On October 21 at 19:14 UTC, Wiz flagged post-exploitation activity in the issue: according to Wiz, the attacker began checking whether the stolen AWS credentials were valid about 4.5 hours after exfiltration, which makes rotating keys urgent rather than optional. This is LiteLLM's second compromise this year; the maintainers say they hardened the release pipeline after an incident in March. How the attacker first reached that deployment was still unconfirmed in the maintainers' latest update, and no GitHub security advisory had been published when we checked. Pin explicit versions, and verify image digests rather than floating tags, until LiteLLM publishes its full post-mortem.

Go to the source

Sources & further reading

Based on the official documentation below. Features and access can change; check the provider before making a decision.

Was this page useful?

Help us make our coverage more useful. This is feedback on the page, not a rating of the tool.