LiteLLM Supply Chain Attack: What Happened and What to Do Now

The LiteLLM supply chain attack of October 21, 2026 is the most important AI infrastructure security story of the year so far, because of where LiteLLM sits. It is the gateway thousands of teams put between their applications and their model providers, which means it holds exactly the credentials an attacker wants most. This post explains what happened, how the malware worked, what to do in the first hour if you were exposed, and the durable defenses every team running AI agents should take from it.

What happened on October 21

In the early morning of October 21, LiteLLM's release pipeline was compromised and used to publish a poisoned v1.107.0 to PyPI and to the official Docker and GHCR container registries. The malicious PyPI wheels were live for about two hours, from 11:39 to 13:23 UTC, and the compromised container tags (v1.107.0, latest, main-latest, and main-stable) pointed at attacker-built images from 11:46 to 14:20 UTC. All previous versions are safe, the affected artifacts have been pulled, and enterprise customers on LiteLLM's private registry were not impacted. Source

The exposure rule is simple. If you installed LiteLLM with an unpinned version during that window, or pulled one of those container tags during that window, treat the environment as compromised. The maintainers advise pinning to 1.106.2 or any explicit earlier version. Source

Why this one matters more than a typical package compromise

Scale is the first reason. LiteLLM is a popular Python proxy library for LLM providers with about 23 million weekly downloads, so even a two-hour window catches a large number of automated builds and unpinned installs. Datadog Security Labs also notes this is the second supply chain compromise of LiteLLM in 2026; the earlier incident, affecting versions 1.82.7 and 1.82.8, was linked to TeamPCP activity, and no connection between the two has been established. Source

The second reason is camouflage. The malicious fork's name differed from the real one by a single hyphen, and the poisoned artifacts went out through the normal release channels with build provenance that faithfully recorded the fork as the source. Casual review of the release page would show nothing unusual. Source

The malware ran on Python startup, no import needed

Microsoft Security Research's analysis of the compromised wheels shows why this incident reaches further than teams actively running a LiteLLM gateway. The package planted files named cook.pth, cook.py, and sitecustomize.py into the Python environment's library directory, outside the normal litellm application folder. Python processes executable lines in .pth files and imports sitecustomize during normal interpreter startup, so simply starting Python in an affected environment could run the payload, even if nothing ever imported LiteLLM. Developer laptops, CI agents, test systems, and containers were all in scope. Source

This has one immediate consequence for responders: do not run python or pip inside a suspect environment to check whether it is affected, because that check itself fires the payload again. Investigate from outside with trusted tools. Source

What the credential stealer went after

The collector, which identifies itself as PRIVCOLLECT, runs as a daemon thread and works through a target list that reads like a map of a modern AI team's secrets: authentication and configuration files for AI assistants, IDEs, GitHub Copilot, VS Code, and MCP integrations; git credentials and package-manager configuration; AWS, Azure, and Google Cloud credential caches plus instance metadata; Kubernetes service-account files and Docker configuration; Chromium and Firefox credential data and browsing history; shell and database-client histories; its own process environment and, on Linux, other processes' environments through procfs; SSH, GPG, TLS, CI/CD, and Vault material; and, when prerequisites are met, selected credential and model-configuration records from the LiteLLM proxy database itself. Source

Collected data was encrypted per run with AES-256-CBC, the key wrapped with an embedded RSA-4096 public key, and uploaded to an endpoint on a lookalike domain, www.litellm.dev, disguised as a healthcheck. A separate Unix-oriented loader in sitecustomize.py was built to fetch and execute second-stage code from a server pointed to by a mutable, GitHub-hosted domain file. That second-stage retrieval was not confirmed in the wild, but the mechanism made the package re-armable even after the initial payload was understood. Source

How the attacker got the pipeline

LiteLLM's own incident report describes a chain of compromises rather than a single failure. The team had temporarily expanded release permissions for two engineers. The attacker held three developers' GitHub CLI OAuth tokens, which LiteLLM believes were harvested from logs of an internal LiteLLM deployment that was exposed to the public internet; their investigation observed situations in which Claude Code embedded a user's GitHub CLI OAuth token into a response body, and those response bodies appeared in the deployment's logs. One stolen token belonged to a GitHub organization owner, which let the attacker disable branch protections, force-push a change that repointed the release workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and sign and publish the poisoned artifacts. This is the second supply chain incident for the project this year, after one in March. Source

Treat the token-logging part as what it is: the maintainer's working account of their own breach, published while the investigation continues. The durable lesson does not depend on it. AI coding tools and gateways see everything you paste or pipe through them, and anything they log becomes a credential store you did not mean to build.

The first hour if you were exposed

The maintainers' response runbook, credited to the community member who helped detect the incident, is deliberate about order. From the shell, without starting Python, delete cook.pth, cook.py, sitecustomize.py, and any matching compiled cache files from every affected site-packages. Kill the detached Python daemon, which holds /tmp/remote_code_loader.lock. Reinstall pinned to litellm==1.106.2, or better, rebuild images and virtual environments from scratch. Source

Then assume exfiltration. If 1.107.0 was ever installed on a host with outbound internet access, rotate everything that host could reach: the instance or task IAM role, every provider key stored in the LiteLLM proxy database plus the master and virtual keys, the DATABASE_URL password, and any secret present in any process environment on the host. Check CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of those credentials from outside your infrastructure. Source

The durable fixes for teams running AI agents

Pin everything. Every Python dependency, and every container image by digest rather than by mutable tag. The entire exposure window existed because unpinned installs and floating tags like latest silently moved to the compromised release. Microsoft's guidance is explicit that digests identify immutable content while tags do not. Source

Treat your LLM gateway as the credential hub it is. It holds provider keys, database strings, and tenant routing data, so it deserves the same isolation, egress controls, and audit logging as a secrets manager. An internal gateway deployment should never be reachable from the public internet. And be deliberate about what AI tools can write into logs: prompts, responses, and tool outputs that contain tokens are a breach waiting for a reader.

Finally, have the response order rehearsed. This incident punished the natural instinct to investigate with the very interpreter that was compromised. Our AI agent security checklist covers the standing controls, and our guide to MCP server security best practices covers the integration layer where agent credentials concentrate.