LiteLLM release pipeline hijacked again: infostealer shipped as v1.107.0 on PyPI and Docker Hub
On the morning of October 21, 2026, a malicious release of LiteLLM landed on PyPI and in the project's official Docker images. Version 1.107.0 carried a credential stealer and a remote-code loader instead of the code its maintainers had written. According to LiteLLM's own security update, the release pipeline itself was compromised, using leaked GitHub credentials from the project's developer accounts. The bad wheels spent under two hours on PyPI, and the tainted Docker tags lived through the afternoon. In an ecosystem of automated builds and pinned dependencies, that was long enough to matter.
A clean tag, a poisoned build
The disclosure reads like a checklist of how fragile package trust is. LiteLLM reports that the attacker obtained GitHub CLI OAuth tokens from three developer accounts, apparently captured in the logs of an internet-exposed internal LiteLLM deployment — one of the accounts belonged to a GitHub organization owner. With those credentials, branch protection was overridden, a workflow change was force-pushed, and the release pipeline was pointed at a lookalike repository: Berri-AI/litellm, one hyphen away from the real BerriAI/litellm. The official v1.107.0 git tag stayed clean; the malicious artifacts were compiled from the impostor repo."This version contained compiled malware which steals credentials and loads remote-code execution tools." — LiteLLM's security update, October 21, 2026Detection, at least, was fast. As BleepingComputer reports, security firms including Socket and Endor Labs flagged the release within roughly six minutes, and PyPI had removed the wheels by 13:23 UTC, with Docker Hub cleaned later that afternoon. LiteLLM says customers on its private enterprise registry were unaffected. Six minutes still counts when the package draws around 92 million downloads a month and companies like NVIDIA, Netflix and Okta number among its users, per BleepingComputer's reporting.
What the stealer goes looking for
The payload's mechanics explain the blunt response guidance. The wheels dropped three files — cook.pth, cook.py and sitecustomize.py — into Python's site-packages directory. Python executes those file types at every interpreter start, so any Python process on a machine ran the malware even if LiteLLM was never imported. Datadog Security Labs' technical breakdown adds that uninstalling the litellm package does not remove the files; they have to be deleted by hand. Kodem's incident analysis documents what the stealer was built to collect:- Cloud and infrastructure credentials: AWS, Azure and GCP keys including instance-metadata tokens, plus Kubernetes, Docker and Terraform secrets
- AI-specific material: LLM provider API keys, credentials stored in the LiteLLM proxy database, and session files from AI coding tools
- Developer and registry tokens: Git credentials, GitHub, npm and PyPI tokens, SSH, GPG and TLS keys
- Local secrets: .env files, environment variables, shell and database histories
- Browser data: saved passwords, cookies and autofill entries
Second pipeline incident of the year
This is LiteLLM's second compromised release of 2026. In March, a threat actor tracked as TeamPCP backdoored versions 1.82.7 and 1.82.8 after breaching a Trivy scanner inside the project's CI/CD pipeline and stealing a PyPI token. Datadog links the two campaigns only by their target: no connection between the actors has been established. The pattern is the uncomfortable part — a gateway that sits in the middle of thousands of AI stacks, holding provider keys and cloud credentials, has now had its distribution channel corrupted twice in eight months.The first hour, per the runbook
Kodem paired its indicators with a first-hour response runbook, and LiteLLM's advisory is just as blunt. The shared core:- Block litellm 1.107.0 at the package proxy, stop deploying floating tags such as latest, and pin the last clean release, 1.106.2, by hash — images by digest
- Do not run python or pip on affected hosts before cleanup, because every interpreter start re-executes the payload
- Isolate hosts and containers, then manually delete cook.pth, cook.py, sitecustomize.py and their compiled .pyc files
- Rotate from a clean machine: cloud roles, provider keys stored in the proxy database, LiteLLM master and virtual keys, the database password, registry and GitHub tokens
- Review cloud audit logs for GetCallerIdentity calls and credential use from unexpected infrastructure since 11:39 UTC on October 21