LiteLLM PyPI Supply Chain Attack Steals AI Dev Credentials

Attackers broke into LiteLLM's release pipeline on October 21 and pushed a poisoned package to PyPI and Docker registries. The infected version, 1.107.0, ran on Windows, Linux, and macOS. Any developer or team that installed it should treat every credential in that environment as compromised.

LiteLLM is an open-source tool made by BerriAI. It gives applications a single interface to large language model providers such as OpenAI, Anthropic, and Google Gemini. The project gets about 23 million weekly downloads and is used by companies including NVIDIA, Netflix, AT&T, and Okta. That reach makes a hijacked release especially damaging.

How the Pipeline Was Compromised

Researchers at Wiz traced the attack to malicious commits pushed from a lookalike GitHub account. The account used a hyphenated name - github.com/Berri-AI/litellm - that closely mimics the real BerriAI organization. Those commits fed three poisoned files into LiteLLM's build process.

The attacker left LiteLLM's application code untouched. Only the installation package was modified. Three files - cook.pth, cook.py, and sitecustomize.py - were dropped into the Python library directory. Socket researchers noted that "during normal startup, Python processes executable .pth lines and then attempts to import sitecustomize," meaning both the infostealer and a remote-access trojan fire before any application code runs. Security firm Endor Labs added that running pip to inspect a suspicious install was enough to trigger the payload.

What the Malware Collected

The infostealer sits inside cook.py. It works across 16 modules and targets a wide range of data.

On the browser side, it pulls saved passwords, cookies, and browsing history from Chrome, Firefox, Edge, and Safari. On the cloud side, it collects AWS credentials from ~/.aws/ and grabs environment variables. It also takes EC2 and ECS instance metadata, Google Cloud Platform service account keys, and Microsoft Azure CLI tokens.

Because LiteLLM works as a gateway to AI providers, the malware also captured API keys for OpenAI, Anthropic, Cohere, and other LLM services. SSH private keys, GPG keys, shell history files, and CI/CD pipeline credentials were taken as well.

The stolen data was encrypted with AES-256-CBC. The encryption key was then wrapped with an RSA-4096 public key. The full package was sent by HTTP POST to an attacker-controlled domain. The third file, sitecustomize.py, ran as a remote-access trojan. It spawned a background process that polled attacker infrastructure every hour and pulled down fresh code for execution on the host.

How to Check Your Exposure

According to The Register, the malicious version was uploaded at 11:39 UTC. Multiple security firms detected the release within six minutes of it going live, according to BleepingComputer. PyPI quarantined the build within hours. The Docker image was removed from Docker Hub and GHCR shortly after. Still, teams that rely on automated dependency updates may have run the infected version without realizing it.

Aikido Security researcher Ilyas Makari advises checking for two specific files. Finding /tmp/.pc_once_* means the infostealer already ran and data left the machine. Finding /tmp/remote_code_loader.lock means the remote-access daemon ran or may still be active. Both checks apply to anyone who ran the Docker image litellm/litellm:1.107.0 under any tag, including latest, main-latest, and main-stable.

Affected systems should be isolated and rebuilt from clean backups. Removing the LiteLLM package alone is not enough. Startup files or an active loader process may still be present. The recommended recovery version is 1.106.2, the last clean release before the attack. Every credential, API key, and secret stored in any affected environment should be rotated without delay. Aikido, Wiz, and Socket have each published detailed mitigation guidance.

A Second Breach in Less Than a Year

October's attack is not LiteLLM's first supply chain incident. Earlier this year, a group called TeamPCP gained access to Aqua Security's Trivy scanner - a tool wired into LiteLLM's CI/CD pipeline - and used that foothold to slip malicious packages into LiteLLM's PyPI distribution. Security firm CloudSEK estimated that the March incident put roughly 2,500 organizations at risk, along with more than 434,000 CI/CD pipelines around the world.

LiteLLM's project maintainer confirmed that customers on the private enterprise version were not affected by the October attack. The maintainer's post-mortem stated that "this version contained compiled malware which steals credentials and loads remote-code execution tools." BerriAI did not respond to press inquiries before publication, according to The Register.

Why AI Developer Tools Are a Growing Target

LiteLLM's design makes it unusually valuable to attackers. It sits between application code and multiple AI providers at once. A single compromised install can yield API keys for several AI services, alongside cloud identities, database connection strings, and CI/CD tokens. Most developer packages touch one or two credential types. An AI gateway routinely touches many.

The broader shift matters too. AI development tools have moved quickly from side projects to production infrastructure. Many teams now run AI gateways and LLM proxies inside automated build pipelines. Those pipelines carry elevated permissions and access to multiple cloud accounts. That combination makes them high-value targets for attackers looking for wide reach with a single strike.

Build pipelines are particularly exposed. They pull packages from public registries on every deployment. A developer might audit a dependency once and then trust it indefinitely. Automated systems rarely re-verify packages they have used before. Attackers time their uploads to catch those pipelines mid-run, before anyone notices a new version exists.

The project has 61,800 GitHub stars and 92 million monthly downloads on PyPI. Those numbers reflect how deeply LiteLLM is embedded across AI development work today. Two successful intrusions against the same project within months suggest that well-resourced threat actors view AI developer tooling as a repeatable path to high-value credentials across many organizations at once. For security teams, the practical response is to treat open-source AI tools with the same scrutiny applied to cloud infrastructure, including integrity checks, pinned versions, and regular rotation of all stored credentials.