LiteLLM — the Python library with 92 million monthly downloads that routes calls to OpenAI, Anthropic, and virtually every LLM in production — shipped a credential stealer and persistent backdoor in version 1.107.0 on PyPI today. If you installed it between 11:39 and 13:40 UTC on October 21, treat every secret accessible to any Python process on that machine as compromised. This is LiteLLM’s second supply chain attack targeting AI developer tooling in 2026, and the mechanics are nastier than the first.
The .pth Trap: It Runs in Every Python Process #
Three files were injected into all seven platform wheels: cook.pth, cook.py, and sitecustomize.py. Most supply chain attacks contaminate the library they target. This one used Python’s own initialization mechanism to break out of LiteLLM entirely.
Python automatically processes every .pth file in site-packages at startup, before your application code runs. cook.pth contains one line: import cook. That launches the stealer in a daemon thread in every Python process on the machine — your Django app, your data science notebook, your CLI tools, unrelated scripts. Wiz identifies this as the first documented wild case using dual persistence via both .pth and sitecustomize.py simultaneously. Installing one package contaminated the entire Python environment.
Everything the LiteLLM Supply Chain Attack Took #
The embedded privcollect payload ran 16 collection modules. The list is comprehensive: cloud credentials (AWS, Azure, GCP, Kubernetes, Docker), AI tool tokens (Claude, Copilot, Cursor, Gemini, Hugging Face, Ollama), browser passwords and cookies across Chrome, Firefox, Edge, and Brave, SSH and GPG private keys, CI/CD secrets from Jenkins, GitLab Runner, Vault, and Terraform, and shell histories.
The most damaging angle for organizations running LiteLLM as an API gateway: the stealer ran a direct SQL query against the LiteLLM Proxy database — SELECT * FROM "LiteLLM_CredentialsTable" LIMIT 500 — harvesting every upstream LLM provider key stored in the system. One query drains an entire company’s AI API credentials. Collected data was encrypted with AES-256-CBC, RSA-4096 key-wrapped, and exfiltrated to http://www.litellm.dev/healthcheck. Full technical details are documented in Socket.dev’s supply chain compromise analysis.
The Backdoor That Survives Uninstall #
The second payload is worse in the long run. sitecustomize.py forked a detached background daemon that runs hourly: it fetches a Python script from an attacker-controlled GitHub repository and executes it via asyncio. The attacker retains arbitrary code execution on any machine that ran the malicious package — indefinitely, even after LiteLLM is uninstalled. Removing the package does not kill the running background process or invalidate credentials already stolen.
How the Build Chain Was Poisoned #
The GitHub source was clean. The attack exploited a lookalike repository: Berri-AI/litellm (with a hyphen) instead of the legitimate BerriAI/litellm. LiteLLM’s release workflow accepted a source_owner override parameter — the attacker passed the hyphenated repository name, redirecting the build to clone from the malicious source. Socket.dev’s analysis shows the malicious build ran from 10:51:23 to 11:06:31 UTC. All seven wheels shipped with the three injected files, byte-for-byte matching the lookalike repository’s payload.
However, this is not a one-time opportunistic hit. This is LiteLLM’s second build pipeline compromise in eight months. The March 2026 incident used a poisoned Trivy security scanner to publish malicious versions 1.82.7 and 1.82.8. The pattern suggests the build pipeline is a sustained, targeted attack vector.
What to Do Right Now #
Check Python site-packages for cook.pth, cook.py, and sitecustomize.py. Check for lock files at /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_.lock. If present, treat the machine as compromised. Moreover, check for the environment variable PRIVCOLLECT_ACTIVE=1 as another indicator of compromise.
- Rotate all credentials from a clean machine — not the affected one
- Block
litellm.devandwww.litellm.devat the network level - Audit containers, CI runners, and environments where Python ran after installation
- Do not use pip or Python as your first remediation step — use OS-level tools to inspect the filesystem
- Review cloud, identity provider, and registry audit logs for unauthorized credential usage
Full IOC lists, SHA-256 hashes, and detailed remediation steps are available from SafeDep’s technical breakdown and OpenSourceMalware’s analysis.
AI Tooling Is the New Tier-1 Attack Surface #
The 2026 pattern is hard to ignore: the Aoki infostealer targeting AI coding credentials, the npm supply chain risks prompting GitHub’s Package Firewall, and now two LiteLLM compromises in one year. Attackers have worked out that the AI developer stack is a force multiplier — compromising one library harvests cloud keys, AI provider tokens, and developer credentials in a single operation. LiteLLM’s 92 million monthly downloads made it the highest-value target in that stack.
Furthermore, PyPI still has no automated build provenance validation. The source_owner dispatch parameter should have been locked to an approved list. SLSA Level 3 provenance would have flagged the lookalike repository mismatch before the wheels were published. One final irony, noted by Wiz: the malware code itself shows hallmarks of LLM-generated code — verbose variable names, defensive error handling, dead code modules. The tool used to steal AI credentials was probably written by one.