LiteLLM compromised for the second time this year: infostealer in version 1.107.0

LiteLLM has been compromised again. On October 21, 2026, attackers used the project's official release pipeline to publish a poisoned version 1.107.0 to PyPI, Docker Hub and GHCR. It carries an infostealer with remote access capabilities. LiteLLM was also hit back in March, so this is the second supply chain attack on the project this year.

LiteLLM is a widely used open-source proxy that routes requests to many LLM providers through a single interface. According to BleepingComputer, the package gets around 92 million PyPI downloads a month. That's what makes it such an attractive target: a LiteLLM host holds the API keys for every AI provider connected to it.

What happened

A supply chain attack goes after the way software is delivered rather than the software running on your machine. In this case the target was the release pipeline. According to LiteLLM's incident report, the artifacts were available during these windows (UTC, October 21):

• PyPI: litellm==1.107.0, seven wheels for Linux, macOS and Windows, from 11:39 to 13:23
• Docker Hub: tags v1.107.0, latest, main-latest and main-stable, from 11:46 to 14:20
• GHCR: the same tags for the litellm, litellm-database and litellm-non_root images, until 13:51

Customers on the private enterprise edition were not affected. The official source tag on GitHub is clean, because the build came from a lookalike repository called Berri-AI/litellm (the real one is BerriAI/litellm). SecurityWeek puts the downloads at more than 49,000 based on PyPI data. Keep in mind that downloads don't equal 49,000 infected systems.

What the malware does

The malicious code isn't in LiteLLM itself. It sits in three files in the site-packages directory (cook.pth, cook.py, sitecustomize.py), which Python loads every time the interpreter starts. So the malware runs even if LiteLLM is never imported, and even when you run pip to investigate.

According to Help Net Security and BleepingComputer, it collects credentials for AWS, Azure, Google Cloud, Kubernetes and Docker, Git, SSH and GPG keys, .env files, shell histories, browser logins and cookies, plus auth files for AI tools such as Claude, Codex, Gemini and Cursor. It also tries to read the provider keys stored in the LiteLLM database. A separate loader checks a GitHub-hosted source every hour for more Python code to run.

The attackers actually used what they stole. About four and a half hours after exfiltration, Wiz saw them validating stolen AWS credentials and testing access to Amazon Bedrock models. That points to LLMjacking, where attackers run AI workloads on stolen credentials and the victims pay for it.

What has changed since my post

In my post I said the attackers used hijacked GitHub CLI OAuth tokens, and that's still true. What the first version of the incident report got wrong was where those tokens came from. LiteLLM initially suspected they leaked through logs on an internal deployment that was exposed to the internet. The corrected root cause analysis from October 23 tells a different story. In May, an admin key for an internal agent platform was accidentally committed to a public repository, and nobody ever revoked it. On October 10, the attackers used that key to get a GitHub organization owner's token. From there they took the tokens of other maintainers, and on October 21 they used them to take over the release pipeline. LiteLLM itself says its earlier assumptions turned out to be "inaccurate or incomplete."

The takeaway is that this didn't start with a clever zero-day. It started with a leaked key that stayed valid for months.

What you should do now

• Check whether LiteLLM 1.107.0, or any of the Docker tags listed above, is in your projects, CI runners or images. If you pulled latest or main-stable during the window, you may be affected without realizing it.
• Don't start Python or pip first in a suspect environment. Search the file system for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py instead. LiteLLM notes that finding nothing doesn't prove a system is clean.
• Rebuild, don't repair. Isolate affected systems, rebuild virtual environments and images from scratch, and pin to litellm==1.106.2 or another release from before the incident. Updating alone is not enough.
• Rotate everything the host could reach: cloud roles and keys, every provider key in the LiteLLM database, master and virtual keys, database passwords, SSH keys and any tokens in environment variables.
• Check your logs. In AWS CloudTrail, look for GetCallerIdentity calls around the time of installation and for your credentials being used from outside your infrastructure.

My advice goes beyond this one incident. An AI gateway is effectively a vault for API keys, so treat it like one. Pin versions instead of using latest, reference images by digest, and let new releases sit for a few days before you deploy them. If you publish software yourself, revoke leaked keys right away, even when the leak looks harmless. There's no CVE for this incident so far, which means you can't count on your vulnerability scanner to flag it.

Sources

• LiteLLM: Security Incident Oct 21, 2026
• LiteLLM: Root cause analysis / attack chain
• BleepingComputer: LiteLLM release pipeline hacked to distribute info-stealer malware
• Help Net Security: LiteLLM compromised in supply chain attack
• SecurityWeek: LiteLLM Compromised in Fresh Supply Chain Attack