LiteLLM 1.107.0 was compromised on PyPI and Docker: what to do

A malicious LiteLLM 1.107.0 was published to PyPI and LiteLLM's Docker registries on October 21, 2026. LiteLLM says its "release pipeline was compromised" and that the version "contained compiled malware which steals credentials and loads remote-code execution tools." In its incident post, LiteLLM says to pin version 1.106.2, remove the malware and rotate credentials.

#What changed?

LiteLLM is an AI gateway that provides a common interface for LLM providers, and it gets about 23 million weekly downloads, according to The Register, Socket and Datadog.

Affected, per LiteLLM:

LiteLLM says "The official v1.107.0 source tag in GitHub does not contain the malicious files" and that the artifacts "were built from an attacker-controlled repository." It says "Enterprise Customers running the private enterprise release of LiteLLM were not impacted."

As of October 22, 2026, PyPI lists 1.106.2 as the latest release, and 1.107.0 is no longer available. A dotsbot.co check of Docker Hub the same day found the latest, main-latest and main-stable tags pointing to the v1.106.2 image.

LiteLLM also says "All previous versions are safe." That is LiteLLM's claim. Versions 1.82.7 and 1.82.8 were compromised in a separate incident earlier in 2026, according to Datadog and the OSV record MAL-2026-2144; JFrog dates that first compromise to March 2026. Socket says its investigation "did not certify every earlier artifact as clean."

#What the malware does

Researchers describe it at a high level. Socket says the release "contains malicious Python startup files that collect cloud credentials, private keys, browser data, and authentication files for AI development tools," and that "a normal Python startup can activate them without the application importing LiteLLM." Datadog says it "targets cloud, developer, AI-tool, browser and LiteLLM proxy credentials," including the provider keys the proxy stores in its database. Researchers say a second component could fetch and run more code, but JFrog says it was "dormant at observation time."

Only Wiz reports use of the stolen credentials: "Wiz Research has observed abuse of stolen credentials, starting approximately 4.5 hours post-exfiltration." Wiz says the attacker checked AWS instance role credentials taken from CI runners and Kubernetes nodes between 16:20 and 17:01 UTC. LiteLLM has not commented on Wiz's finding.

#Who is affected and when?

LiteLLM says: "You are affected if you used an unpinned version of LiteLLM between 11:39 and 13:23 UTC via pip or if you used the docker image v1.107.0, latest, main-latest, or main-stable between 11:46 and 14:20 UTC." It adds: "If you ran pip install on LiteLLM v1.107.0 or started the docker image in the compromised interval, assume it is compromised."

Socket notes that "Deployments following a floating tag could therefore receive the affected release without explicitly selecting 1.107.0."

#How to check whether you were hit

• LiteLLM says "If an environment started Python with litellm==1.107.0, treat that environment as compromised."
• LiteLLM suggests checking the installed version with pip show litellm. It also warns that any Python start in an affected environment, including pip, runs the malware again.
• Socket suggests you "Check lockfiles, caches, build logs, container layers, and running image digests, including deployments that used floating tags."
• LiteLLM lists filesystem evidence to search for in its post, and says "Finding one confirms exposure, but not finding one does not prove the environment is clean."

#What should you do?

LiteLLM's steps, in its order. First, it says: "Don't start with pip install."

1. From a shell, delete the startup files LiteLLM lists in its incident post from every affected site-packages directory.
2. Stop the detached Python background process LiteLLM describes.
3. "Reinstall pinned to litellm==1.106.2." LiteLLM adds: "Rebuilding images and venvs from scratch is better." For Docker, use the v1.106.2 image.
4. "If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded."
5. "Rotate everything listed above that the host could reach." LiteLLM names, in particular:

• "the instance/task IAM role"
• "every provider key stored in the LiteLLM proxy DB, plus the master and virtual keys"
• "the DATABASE_URL password"
• "any secret that was in the environment of any process on the host"

6. "Check CloudTrail for GetCallerIdentity from the instance role around install time, then for use of the role's credentials from outside your infrastructure."

LiteLLM says the instructions came from the researcher who helped it detect the incident. The Upwind security research team first reported the compromise in a GitHub issue at 12:06 UTC on October 21. Datadog advises rotating credentials "From a clean machine."

#How did it happen?

This is LiteLLM's account, which it says it is still confirming. LiteLLM says "The attacker had access to three sets of developer GitHub CLI credentials," one of which "belonged to one of our two GitHub organization owners." It says the attacker used it to disable branch protections, then ran the release workflow against a lookalike repository, which Socket says differed "by one hyphen from the legitimate BerriAI/litellm project."

On where the tokens came from, LiteLLM says it has "observed specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body," and that such tokens "may appear in LiteLLM logs." It says it believes the attacker reached an internal LiteLLM deployment exposed to the public internet and took the tokens from its logs. That is LiteLLM's claim about Anthropic's product, and no response from Anthropic appears in our sources. LiteLLM says it has "not yet confirmed how the attacker gained access" and suspects "a recently patched vulnerability."

LiteLLM says "All tokens which were involved in this attack have been revoked" and, as of 02:19 UTC on October 22, 2026, that "regular LiteLLM releases remain paused." BerriAI, which develops LiteLLM, did not respond to The Register.

#How does it compare?

This is LiteLLM's second supply-chain compromise in 2026. Datadog says "No connection between the two compromises has been established at time of writing," and JFrog says the incidents "should be treated as separate campaigns." For another case of exposed provider keys, see our coverage of the OpenCode console breach. For agent security controls, see Microsoft's agentic insider security controls. More is in our Privacy and Security hub.

#What is still unclear?

• How the attacker got in. LiteLLM has not confirmed it.
• The Claude Code token claim. It is LiteLLM's, with no Anthropic comment in our sources.
• Scale. No source gives a download count for 1.107.0 or a number of affected users.
• Who did it. No source names an attacker.
• More detection guidance. LiteLLM says it "will be posting more detail on how specifically to find indication of compromise."
• No CVE yet. The only database record is OSV's MAL-2026-2144.