LiteLLM 1.107.0 Compromised: Credential Stealer Hit PyPI and Docker

One of the most widely used open-source LLM gateways was poisoned for the second time this year. On 21 October 2026, attackers pushed a malicious litellm==1.107.0 to PyPI and the official Docker images, according to LiteLLM's incident report. The PyPI release was live from 11:39 to 13:23 UTC and the Docker Hub tags, including latest, served it until 14:20 UTC. The project says the release "contained compiled malware which steals credentials and loads remote-code execution tools". Socket puts LiteLLM's weekly downloads at about 23 million, per Help Net Security. If your AI gateway auto-pulls latest, this one is yours to check.

What happened

LiteLLM's timeline is unusually precise. At 10:08 UTC branch protection rejected an unauthorised change to the private release workflow; five seconds later a privileged developer credential overrode it. The modified workflow built from an attacker-controlled repository named Berri-AI/litellm, one hyphen away from the real BerriAI/litellm. A second developer credential satisfied the production approval gate, seven malicious wheels went to PyPI at 11:39, container jobs ran at 11:46, and a third credential deleted the workflow records at 11:53.

So the attacker held three engineers' GitHub CLI OAuth tokens: one to change the pipeline, one to approve it, one to clean up. The Hacker News report quotes LiteLLM's director of security saying the actions were taken "through three engineers' GitHub accounts". Two-person approval did exactly what it was designed to do, and it did not help, because both persons were the attacker.

How the tokens leaked is the uncomfortable part, and the first explanation did not survive. The incident post initially suspected the tokens were read from the logs of an internet-exposed internal LiteLLM deployment. Two days later, LiteLLM's root cause analysis, which it calls "the canonical source of truth", told a different story. On 27 May 2026 an administrative key for an internal LiteLLM Agent Platform deployment was committed to a public repository. The file was deleted about three hours later, but the key was never revoked. On 10 October the attacker used it to call the platform's API, which returned the GitHub CLI OAuth token of a GitHub organisation owner. With that token, throwaway CI workflows posted the tokens of two more maintainers to an attacker-controlled endpoint.

What the malware did

The payload did not wait for anyone to import litellm. It dropped cook.pth (a single line, import cook) plus sitecustomize.py into site-packages, so it ran on every Python start in the environment, including pip itself. StepSecurity's analysis, via The Hacker News, calls the stealer "privcollect". It targeted:

• cloud credentials for AWS, Azure, Google Cloud, Kubernetes and Docker;
• Git, SSH and GPG keys, browser data and shell history;
• auth files for Codex, Claude, Gemini and Cursor;
• provider keys and model settings from LiteLLM proxy databases (Help Net Security notes researchers say this shows intent, not that the attackers succeeded).

Data went out as a compressed archive to a "healthcheck" endpoint on litellm[.]dev. A second component forked a daemon that checked a GitHub dead drop every hour for more Python to run.

Wiz observed the stolen credentials in use: about 4.5 hours after exfiltration, the attacker validated AWS credentials from compromised CI runners and Kubernetes nodes and checked access to models on Amazon Bedrock, behaviour Wiz associates with LLMjacking, per Help Net Security.

The numbers

Why it matters

An LLM gateway is a credential vault by design. It holds every provider key, often a database password, and usually runs with a cloud role. That makes it a better target than most libraries, and this is the second time in 2026: the March compromise, linked to TeamPCP, used the same .pth trick. Hudson Rock later tied the stolen data from March to 2,488 corporate domains.

One detail deserves attention from anyone doing signing. LiteLLM rotated its cosign key on 23 October and warned that the compromised 1.107.0 images carry a valid signature from the previous key. Signatures proved the images came from LiteLLM's pipeline. The pipeline was the thing that was compromised.

What sceptics say

The exposure windows were short: under two hours on PyPI and under three on Docker Hub. Enterprise customers on the private registry were not affected, and anyone pinning versions by digest never pulled 1.107.0. Per Help Net Security, Wiz saw the attacker go beyond credential validation (listing IAM roles, users and keys) in only a small number of environments, so the real blast radius is likely far smaller than 23 million weekly downloads suggests. It is also fair to say the root cause was a plain hygiene failure, a leaked key nobody revoked for more than four months, not anything specific to AI tooling.

What it means for engineering and DevOps teams

My take (opinion): treat the AI gateway like the payment service, not like a dev tool. LiteLLM's checks are short enough to run now:

# Run in each venv or image that has litellm; do NOT run pip install first,
# because any Python start re-triggers the payload in an affected environment.
pip show litellm 2>/dev/null | grep -i '^version'
python3 -c "import site,sys; print('\n'.join(site.getsitepackages()))" \
  | xargs -I{} sh -c 'ls {}/cook.pth {}/cook.py {}/sitecustomize.py {}/litellm-1.107.0.dist-info 2>/dev/null'
ls -l /tmp/remote_code_loader.lock 2>/dev/null   # detached daemon marker

If anything shows up, LiteLLM recommends rebuilding the image or venv from scratch and assuming exfiltration if the host had internet access. Then rotate what the host could reach: the instance role, all provider keys in the proxy DB, master and virtual keys, and the DATABASE_URL password. Longer term:

• Pin by digest, never latest, for gateways and anything else holding keys.
• Revoke leaked keys immediately, even when the commit is deleted. Git history keeps them, and this one stayed valid for more than four months.
• Never give agents or bots a personal GitHub CLI token. LiteLLM notes these tokens are unscoped; use a fine-grained token or GitHub App scoped to the repos the service needs.
• Keep internal gateways off the public internet, behind SSO.
• Restrict egress from gateway hosts to the provider endpoints they actually call.

I covered the broader pattern of registry worms in the npm supply-chain post, and the LiteLLM proxy setup guide is worth rereading with a security eye on where the keys live.

FAQ

Which LiteLLM version was compromised?

Only litellm==1.107.0 on PyPI and the Docker tags v1.107.0, latest, main-latest and main-stable during the 21 October 2026 window. LiteLLM says all earlier versions are safe and recommends pinning 1.106.2 or another pre-incident version.

Is upgrading enough?

No. The payload runs from .pth and sitecustomize.py files on every Python start and starts a background daemon, so you need to remove those files or rebuild, then rotate every credential the host could reach.

Was this the same attack as March 2026?

It used the same .pth persistence technique as the March incident linked to TeamPCP, but LiteLLM's root cause analysis does not attribute the October attack to TeamPCP or anyone else, and the entry point was different: a leaked administrative key. For March, LiteLLM's town hall update gives a compromised Trivy scanner in its CI pipeline as its "present understanding", not a final finding.

Related: The Worms Learned to Use Your AI Agent: A Year of npm Supply-Chain Attacks, GitHub Actions Security in 2026: 76 Hijacked Tags and the Fixes That Work and How to Set Up LiteLLM Proxy: Budgets, Fallbacks and Virtual Keys (2026).