LiteLLM says malicious 1.107.0 artifacts were published to PyPI, Docker Hub and GHCR at about 19:40 on October 21, Beijing time, and that the team became aware of them at 21:32. The malicious releases and images have since been removed. Enterprise deployments that pull only from LiteLLM's private registry are not affected. Anyone who installed or ran 1.107.0 should treat the credentials those deployments could access as exposed. The clean version to pin is 1.106.2.

What the malicious package does

According to SafeDep's analysis, the 1.107.0 wheels add three files to site-packages, and two of them run every time Python starts on the host, even in a process that never imports litellm. One is a credential stealer, the other a backdoor that can download and run further code.

SafeDep lists what the stealer collects: SSH keys, cloud credentials (AWS, Azure, gcloud, Kubernetes, Docker), CI/CD secrets, tokens for AI coding tools, browser passwords, environment variables of other processes, and, if a LiteLLM proxy database is configured, the LLM provider API keys stored in it. Because a LiteLLM gateway often holds keys for every provider a team uses, a single infected proxy can expose all of them. For more on how gateways sit between teams and model providers, see OpenAI's new approval rule for routers and AI gateways.

How to check and what to do

First, confirm whether any machine, virtual environment, container image or CI job installed litellm 1.107.0, or pulled a LiteLLM Docker image tagged v1.107.0, latest, main-latest or main-stable during the incident. The remediation in the GitHub issue lists the files the package drops: cook.pth, cook.py and sitecustomize.py in site-packages.

If 1.107.0 was installed, the issue's remediation steps are:

  1. Do not start by running pip install in the affected environment. Any Python start there runs the malicious code again, including pip.
  2. From the shell, delete cook.pth, cook.py and sitecustomize.py, along with their cached .pyc files, from every affected site-packages.
  3. Stop the detached Python background process the backdoor started.
  4. Reinstall pinned to litellm 1.106.2. Rebuilding images and virtual environments from scratch is better. For Docker, redeploy on v1.106.2.
  5. If the host had outbound internet access, assume the credentials were stolen, and rotate everything it could reach: model provider API keys, including every key stored in the LiteLLM proxy database and the proxy's master and virtual keys; cloud credentials and instance roles; SSH keys; CI secrets; the database password; and any secret in the environment of any process on the host.

LiteLLM's own guidance for open-source users is to pin 1.106.2 or another explicit version published before the incident. For another recent developer-tool incident, see the OpenCode Console security incident. On the defensive side, see how AI helped find critical PHP flaws and what website owners should check.

Sources

  • LiteLLM security statement on X (https://x.com/LiteLLM/status/2112945728565993864)
  • LiteLLM GitHub issue #47826 (https://github.com/BerriAI/litellm/issues/47826)
  • SafeDep analysis (https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/)