LiteLLM, the open source library thousands of teams use to route calls across OpenAI, Anthropic, Azure, and other model providers, shipped a backdoored release on October 21, 2026. Version 1.107.0 sat live on PyPI, Docker Hub, and GHCR for roughly two hours before the compromise was caught and pulled. The root cause goes back to May: a master key committed to a public repository that nobody revoked. If your build pulled litellm between 11:40 a.m. and 2:00 p.m. UTC that day, every credential reachable from that machine needs rotating, not just the package.
How a Key From May Turned Into a Hijacked Release
On May 27, 2026, a configuration file containing the master key for LiteLLM’s internal Agent Platform was pushed to a public repository. The commit was force-pushed over quickly, but according to LiteLLM’s own root cause analysis, the key itself was flagged for revocation and then never actually revoked.
That gap sat open for over four months. On October 10, an attacker used the still-live key to pull a GitHub CLI token belonging to an organization owner, then used that access to harvest tokens from two maintainers with release privileges. On October 21, the attacker overrode branch protection, pointed LiteLLM’s release pipeline at a lookalike fork, and pushed a malicious build through both the staging and production approval gates using the two stolen maintainer tokens. LiteLLM 1.107.0 landed on PyPI at 11:39 a.m. UTC, with Docker Hub and GHCR images following minutes later.
An outside researcher flagged the compromise within roughly fifteen minutes, filing a GitHub issue that forced a response. PyPI had quarantined the package by 1:23 p.m. UTC, and Docker Hub tags were pulled or repointed to clean images shortly after. The attacker also deleted the CI run records and force-pushed the main branch back to an earlier commit to cover the trail.
What the Backdoored Package Actually Did
This wasn’t a careless dependency, it was a deliberate payload. According to Microsoft’s technical writeup, the malicious wheel dropped three files, cook.pth, cook.py, and sitecustomize.py, into the Python environment’s site-packages directory, sitting outside LiteLLM’s own install folder. Python runs .pth files automatically on startup, so the credential stealer activated the moment Python launched in an affected environment. You didn’t even need to import LiteLLM.
Once running, it went after almost everything a developer machine or CI runner typically holds: cloud credentials for AWS, Azure, and GCP, SSH and GPG keys, CI/CD and Vault tokens, AI coding tool configs for Copilot and VS Code, browser session data, and shell history. Teams self-hosting the LiteLLM proxy had an extra exposure, the malware could pull up to 500 rows per query straight out of the proxy’s own database, including any provider API keys stored there. Everything collected was encrypted and sent to a URL designed to look like LiteLLM’s own health check endpoint. A second loader could fetch and run further code from a pointer hosted on GitHub, though researchers found that pointer empty when they checked it.
What to Do if Your Pipeline Touched This
Uninstalling the package is the easy part and not the part that matters. Work through this in order:
- Check for
cook.pth,cook.py, andsitecustomize.pysitting in your site-packages directory, separate from the LiteLLM folder itself. Deleting the package alone can leave these behind. - Search every place the bad wheel could still be cached: pip and uv caches, internal package mirrors, lockfiles, and any container images built between 11:40 a.m. and 2:00 p.m. UTC on October 21 that pinned
1.107.0or a mutablelatesttag. - Rotate everything reachable from the affected machine, and do it from a separate, clean machine: model provider keys, cloud credentials, SSH and GPG keys, CI/CD and registry tokens, and browser sessions. Rotating a key doesn’t always kill tokens already issued, so revoke active sessions too.
- If you self-host the LiteLLM proxy, assume its database was queried and treat every credential stored there as burned.
This is the third software supply chain compromise we’ve flagged in the past few months, after the BdThemes attack on Elementor sites and the Rank Math PRO backdoor earlier this month. The pattern is the same each time: one forgotten credential sits unrevoked for months, then becomes the entry point for everything downstream. If your product leans on AI routing libraries the way it leans on any other critical dependency, that dependency deserves the same scrutiny, pinned versions, reviewed updates, and a plan for what happens when one gets compromised. Teams building AI-integrated products who want that chain reviewed can start with our AI development work, and if you’re running autonomous agents on top of these providers, it’s worth reading our earlier piece on how a malicious website can poison a local AI agent too.
