LiteLLM 1.107.0 PyPI compromise: which versions and Docker tags were affected, how to check, and what to rotate

The LiteLLM 1.107.0 PyPI compromise happened on October 21, 2026, when LiteLLM's own release pipeline published version 1.107.0 of the popular Python LLM gateway with malware built in. Every 1.107.0 wheel, and four Docker image tags, carried a credential stealer and a backdoor that fetches new code through GitHub. It is the second time in 2026 that LiteLLM releases on PyPI were poisoned, and a security problem for anyone whose servers or laptops installed it during a window of about two hours.

This guide is based on LiteLLM's incident report and its March 2026 security update, GitHub issue #47826, analyses by SafeDep, Socket, StepSecurity, JFrog and Wiz, the PyPI project page, and coverage by Help Net Security and The Hacker News, checked October 22 and re-checked October 23, 2026. Exposed LiteLLM servers were also the target of the PoeLLM botnet that Black Lotus Labs reported on October 7, 2026, covered in our PoeLLM story.

The short version

• Bad version: litellm==1.107.0, all seven wheels, plus Docker tags v1.107.0, latest, main-latest and main-stable.
• Safe: 1.106.2, which PyPI still lists as the latest release on October 23, and earlier explicitly pinned versions, LiteLLM says.
• Windows of exposure: PyPI 11:39 to 13:23 UTC; Docker Hub 11:46 to 14:20 UTC, all on October 21.
• What it steals: cloud, SSH, CI/CD and AI-tool credentials, browser passwords, and every LLM provider key stored in a LiteLLM proxy database.
• What to do: remove the files before running Python again, rebuild, and rotate everything the host could reach.

Is LiteLLM safe to use?

Version 1.107.0 is not. LiteLLM's incident report says "all previous versions" are safe and tells users to pin 1.106.2 "or any explicit version published prior to now." PyPI removed 1.107.0 by 13:23 UTC on October 21, and on October 23 the project page still listed 1.106.2 as the latest release. LiteLLM said on October 22 that its registries "remain locked to new releases" and that regular releases are paused.

The malicious code isn't in LiteLLM's source code. The official v1.107.0 Git tag doesn't contain it, LiteLLM says; the artifacts were built from an attacker-controlled lookalike repository, Berri-AI/litellm (with a hyphen). Enterprise customers who pull from LiteLLM's private registry were not affected, the company says.

The bigger question is the release process. In March, litellm 1.82.7 and 1.82.8 were poisoned after, LiteLLM believes, credentials stolen through a compromised Trivy scanner gave attackers access to its publishing pipeline. Those packages were live for about 40 minutes on March 24, 2026. JFrog, Socket and others say there is no evidence linking the two incidents. Socket says litellm gets about 23 million downloads a week, which is why two short windows still matter.

Which LiteLLM versions and images are compromised?

Last verified: October 23, 2026

Wiz gives slightly earlier takedown times (PyPI quarantine by 13:20 UTC, Docker tags around 13:53). StepSecurity says some PyPI mirrors kept serving cached 1.107.0 wheels after PyPI removed the release, so a private mirror can extend the window.

How did the attackers publish it?

With stolen developer credentials, not a hacked PyPI account. According to LiteLLM, three engineers' GitHub accounts were used, apparently through stolen GitHub CLI OAuth tokens. One token belonged to one of LiteLLM's two GitHub organization owners. At 10:08 UTC it was used to override branch protection and change the private release workflow, which at 10:46 began building from the lookalike repository. LiteLLM says that on Monday, October 19, it had temporarily widened release permissions so two engineers could publish daily bugfix backports for customers. A second account approved the production release at 11:11, and at 11:53 a third deleted the workflow records, which limited the logs available to investigators. The official pipeline built, signed and published the artifacts in between. The first public report, GitHub issue #47826, came at 12:06 UTC, according to StepSecurity's timeline.

How LiteLLM 1.107.0 was published and pulled, October 21, 2026 (UTC)

1. 10:08Developer credential overrides branch protection on the release workflowLiteLLMConfirmed
2. 10:46Modified workflow builds from the lookalike Berri-AI/litellm repoLiteLLMConfirmed
3. 11:11Second developer credential approves the production releaseLiteLLMConfirmed
4. 11:39Seven malicious wheels uploaded to PyPILiteLLMConfirmed
5. 11:46Malicious Docker images publishedLiteLLMConfirmed
6. 11:53Third credential deletes workflow recordsLiteLLMConfirmed
7. 12:06First public report, GitHub issue #47826StepSecurityReported
8. 13:23PyPI has removed 1.107.0LiteLLMConfirmed
9. 14:20Docker Hub tags removed or repointedLiteLLMConfirmed

• Confirmed
• Reported

How the attacker got the tokens is not settled. LiteLLM's incident report, last updated at 20:30 UTC on October 21 and unchanged on October 23, gives a working theory. The company found an "unexpected, innocuously named user account" on its internal LiteLLM deployment, which was exposed to the internet, and believes "the attacker gained access to this deployment, obtained the GitHub CLI OAuth tokens from its logs," and then used them on the release workflow. It says it has seen situations in which Claude Code embeds a user's GitHub CLI OAuth token in a response body, so "these tokens may appear in LiteLLM logs" when response bodies are logged. It hasn't confirmed how the attacker reached the deployment, suspects "a recently patched vulnerability," and says it is "still working on confirming some of the above." Help Net Security and The Hacker News reported the same account on October 22.

There was no final post-mortem as of October 23. CEO Krrish Dholakia wrote in the GitHub issue on October 22 that the root-cause investigation continues and that LiteLLM will share the changes it is making to its release pipeline. No public response from Anthropic to the Claude Code claim could be found as of October 23.

What does the malware do?

Each 1.107.0 wheel drops three files into site-packages, according to SafeDep, the original issue and LiteLLM:

• cook.pth runs import cook at every Python startup, so the stealer runs in any Python process on the host, even ones that never import LiteLLM.
• cook.py collects SSH keys, AWS, Azure, Google Cloud and Kubernetes credentials, CI/CD secrets, shell history, browser passwords, tokens for AI coding tools such as Claude Code, Cursor, Codex and Copilot, other processes' environment variables, and AWS instance metadata. If DATABASE_URL is set, it dumps the LiteLLM proxy's credential and model tables, which hold provider API keys. The data is encrypted and sent to www.litellm.dev, which isn't LiteLLM's domain.
• sitecustomize.py starts a detached daemon that checks a file in the GitHub repository letters9813/pythonclient-test every hour for a server address, then downloads and runs Python code from it.

The GitHub account was gone about two hours after the release. StepSecurity and the issue's reporter say the file was empty when they checked, so the second stage wasn't armed while the dead drop existed; SafeDep says it couldn't recover any server address and that hosts which ran the daemon earlier may still have received second-stage code. The stealer itself runs as soon as Python starts. Wiz says it saw stolen AWS instance-role credentials being tested from 16:20 to 17:01 UTC, about 4.5 hours after exfiltration, first with an identity check and then with Amazon Bedrock model-listing calls, which it calls consistent with LLMjacking. That is the same pattern as the stolen-key market in our story on stolen AI API keys.

How do I check if I installed LiteLLM 1.107.0?

LiteLLM's report lists these checks. It warns that finding none of them "does not prove the environment is clean."

1. Run pip show litellm in each environment and look for version 1.107.0, or search the filesystem for a litellm-1.107.0.dist-info folder.
2. Search every site-packages directory for cook.pth, cook.py and sitecustomize.py.
3. Check whether any container ran the image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e, or pulled one of the four tags during the window.
4. Look for host markers listed in issue #47826 and by SafeDep: /tmp/.pc_once_72129118c59f5636c0bb, /tmp/remote_code_loader.lock, the environment variable PRIVCOLLECT_ACTIVE=1, and outbound traffic to www.litellm[.]dev.

Projects that depend on litellm without pinning a version could also have pulled 1.107.0 during the window, so check lockfiles and build logs for indirect installs.

What should I do if I was affected?

LiteLLM's steps, in order:

1. Don't start with pip install. Any Python start in the environment re-runs the malware.
2. From the shell, delete cook.pth, cook.py, sitecustomize.py and their __pycache__ files from every affected site-packages.
3. Kill the detached Python daemon holding /tmp/remote_code_loader.lock.
4. Reinstall litellm==1.106.2; rebuilding virtual environments and images from scratch is better.
5. If 1.107.0 ran on a host with outbound internet access, "assume the exfil succeeded."

Then rotate everything the host could reach: the instance or task IAM role, every provider key in the LiteLLM proxy database plus master and virtual keys, the DATABASE_URL password, and any secret in the environment of any process on the host. LiteLLM also says to check AWS CloudTrail for GetCallerIdentity calls from the instance role around install time, and for use of those credentials from outside your own infrastructure. Because the stealer also reads SSH keys, GitHub CLI tokens and AI coding-tool configs, developer laptops that installed 1.107.0 need the same treatment.

To narrow future windows, pin exact versions with hashes and pin Docker images by digest rather than latest. The issue's reporter also asked LiteLLM to adopt PyPI Trusted Publishing with attestations. LiteLLM's report says that after the March incident its publish step already used "Trusted GitHub Publishers," with releases built in a private repository and signed Docker images. The attackers got around that by running LiteLLM's own workflow against the lookalike repository, so the official pipeline signed and published the malicious artifacts. For another critical patch released October 21, 2026 that defenders had to apply within hours, see our PHP2Shell story.

What's confirmed, reported and uncertain

• Confirmed (LiteLLM): the affected artifacts and windows, the three-account attack path, the clean Git tag, 1.106.2 as the version to pin, and the remediation steps.
• Confirmed (PyPI): 1.106.2 is listed as the latest release on October 23, 2026.
• Reported (security firms): the malware's behavior and indicators (SafeDep, Socket, JFrog, StepSecurity), and post-theft AWS credential testing (Wiz).
• LiteLLM's working theory (incident report, not yet confirmed): the exposed internal deployment and the theory that GitHub tokens leaked through logged Claude Code response bodies.
• Uncertain: how many machines installed 1.107.0, how the internal deployment was reached, whether any second-stage code was ever delivered, and when LiteLLM will publish a final post-mortem.