LiteLLM 1.107.0 Shipped a Credential Stealer (October 2026): Affected PyPI Release and Docker Images, and What Users Should Do

The company lists the following affected artifacts. All times are October 21, 2026.

The company says you are affected if you installed LiteLLM with pip without pinning a version during the window, or started a container from one of these tags during the window. If CI runs pip install litellm on every build, or your Dockerfile builds FROM the latest tag, the affected version may have been installed without anyone doing anything.

• Check the installed version with pip show litellm (the company's guidance)
• The company has published the file names to look for and the image digests. Finding them confirms exposure, but not finding them does not prove the environment is clean
• If you had explicitly pinned 1.106.2 or earlier, or 1.107.0rc1 or rc2, you are not affected (the company says all earlier versions are safe)
• Customers pulling from the private enterprise registry were not affected (the company)

According to the reporter's analysis quoted in the company's notice, the malware is installed as files that Python loads automatically every time it starts. It runs again for any Python process, including ones that never import litellm and pip itself.

The cleanup order the company gives is as follows (file names and locations are on its notice page):

• Without starting Python, delete the malicious files the company names (and their cache files) from every affected site-packages directory, from the shell
• Stop the Python process left running in the background
• Only then reinstall pinned to litellm==1.106.2. The company says rebuilding images and virtual environments from scratch is better

If you ran it in containers, the quickest route is usually to stop the containers created from the affected image and recreate them from an image pinned to a clean version (this site's note).

For now the company asks users to pin 1.106.2 or any explicit version published before this incident. As of October 22, the latest version on PyPI is back to 1.106.2 and 1.107.0 has been removed.

In Docker, refer to images by a version tag, or better by digest (a value computed from the image contents), rather than by tags such as latest or main-stable whose contents change. Then a change to what a tag points to does not reach you. The company says regular releases are paused and its registries are locked to new releases. When a new version does appear, it is safer to wait until the company confirms it is clean (this site's note).

The company says that if 1.107.0 was ever installed on a host with outbound internet access, you should assume the stolen data was sent out successfully. It names these in particular:

• The cloud role attached to the server or container (such as an AWS instance or task IAM role)
• Every LLM provider key stored in the LiteLLM proxy database
• The proxy master key and all virtual keys you issued
• The password in the database connection string (DATABASE_URL)
• Every secret that was in the environment of any process running on the host

In the reporter's analysis, the malware was also built to collect SSH keys, Git and package-publishing credentials, Kubernetes tokens, passwords saved in browsers and the settings of AI coding assistants. If you ran 1.107.0 on a developer laptop, the credentials on that laptop need rotating too.

Issue a new key in each service's dashboard and revoke the old one (this site's note: set the new key first, then revoke the old one, to avoid an outage). How to handle API keys is covered in what makes .env files and API keys risky.

The company asks you to check the AWS audit log (CloudTrail) for an identity check call (GetCallerIdentity) made with the instance role around the time of installation, and then for any use of that role's credentials from outside your own infrastructure.

As a note from this site, also check your LLM providers' dashboards for any unexpected rise in usage or charges since 11:39 UTC on October 21 (the evening in Japan). When a stolen LLM key is used, it can show up in usage and billing. What happens with stolen keys is covered in how stolen API keys lead to account bans.

The affected environments were those that installed with pip without a pinned version, or used tags such as latest, main-latest and main-stable whose contents change. Environments that pinned 1.106.2 and referenced Docker images by digest were not affected, even if they were rebuilt during the window.

As a first step, pin the dependencies used in production and CI with a lock file that includes hashes (pip install --require-hashes, or uv or Poetry lock files). A setting that avoids versions published very recently (such as uv's exclude-newer, which ignores anything published after a given time) also helps against releases that are pulled within hours. The approach is covered in auditing dependencies with OSV-Scanner.

The proxy database holds the keys for every provider you connect. When you have to rotate them, as now, not knowing which key belongs to which environment leaves you choosing between missing some or shutting everything down.

Using separate provider keys for development, testing and production, and setting spending limits and alerts on the provider side, keeps the rotation smaller and helps you notice misuse sooner. What to do when a key leaks is covered in an API key that leaked from AI-written code.

The company believes the attacker got into an internal LiteLLM deployment that was exposed to the internet, and that its logs contained developers' GitHub tokens that an AI coding assistant had included in response bodies. If an LLM gateway logs full response bodies, secrets can end up in those logs.

For a gateway you run yourself, check three things: the admin interface and API are not reachable directly from the internet, the logging settings that keep response bodies are reviewed, and if you keep them, the retention period is short. For developers' GitHub tokens, use ones that expire, and keep organisation owner rights separate from the accounts used for day-to-day work, so that a stolen token does less damage. Protecting a GitHub account is covered in setting up GitHub two-factor authentication.