LiteLLM Supply Chain Attack: A Key Never Revoked
The LiteLLM supply chain attack of October 21 did not start on October 21. According to LiteLLM’s own root cause report, a master key committed to a public repository on May 27 was never revoked. An attacker used it on October 10 to reach the GitHub account of an organization owner, and eleven days later published a backdoored LiteLLM 1.107.0 to PyPI and the container registries.
What Happened in the LiteLLM Supply Chain Attack
The malicious package was live on PyPI from 11:39 to 13:23 UTC on October 21. The Docker tags v1.107.0, latest, main-latest and main-stable pointed at a compromised image from 11:46 to 14:20 UTC; the GHCR tags were gone by 13:51 UTC. LiteLLM says its official v1.107.0 source tag is clean: the artifacts were built from an attacker-controlled lookalike repository (Berri-AI instead of BerriAI). LiteLLM describes the payload as compiled malware that steals credentials and loads remote code execution tools. Enterprise customers on its private registry were not affected.
The root cause report lays out the path. The leaked key belonged to an internal alpha service. On October 10 the attacker used it to read that service’s API, which returned the GitHub CLI token of an organization owner, not tied to a service account and not scoped down. Throwaway workflows then sent CI secrets to an external endpoint, including the tokens of two maintainers. On October 21 the attacker pointed the release workflow at the lookalike repository. A merge was blocked, so the owner’s token disabled branch protection. One maintainer’s token started the release, another approved it, and a third deleted the run records. LiteLLM had temporarily let any two engineers trigger and approve releases that week. An outside researcher flagged the compromise about 20 minutes after publication, per LiteLLM.
As of October 26, LiteLLM describes the incident as contained and has said it will share process improvements during the week of October 26.
Why It Matters
The LiteLLM supply chain attack shows how little two approvals on a release can mean. The attacker held valid credentials for both, so both looked legitimate. LiteLLM’s own conclusion: failing to rotate an exposed key made the rest possible.
An AI gateway also sits on a pile of secrets: provider keys in the proxy database, master and virtual keys, the database password. Assumption: DACH mid-sized companies are starting to run LiteLLM or similar gateways in pilots, often installed with an unpinned pip command. For NIS2 supply chain duties and GDPR, the useful evidence is a rotation log showing which keys were replaced and when.
What You Should Do Now
- Check exposure. Run pip show litellm in each environment and look for version 1.107.0. For containers, check whether the image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e ran. Search for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Finding one confirms exposure; finding none does not prove the environment is clean.
- Clean up in the right order. Do not start with pip install: every Python start runs the malicious files again, pip included. Delete cook.pth, cook.py, sitecustomize.py and their cached bytecode from every site-packages directory, stop the Python process that holds /tmp/remote_code_loader.lock, then reinstall pinned to litellm==1.106.2. Rebuilding images and environments from scratch is better.
- Rotate everything the host could reach. If 1.107.0 ever ran on a host with outbound internet, assume the data left. That means the instance or task IAM role, every provider key in the LiteLLM proxy database, master and virtual keys, the DATABASE_URL password and any secret in any process environment on that host.
- Check the logs. In CloudTrail, look for GetCallerIdentity calls from the instance role around install time, then for that role’s credentials used from outside your infrastructure.
DIESEC Perspective
When a secret lands in a public repository, rotate it first and clean the history second. Give automation its own scoped service account instead of an owner’s CLI token, and treat a release approval as only as strong as the accounts that can give it.
Not sure whether a leaked key or an over-broad token still opens your build pipeline? Contact DIESEC for a CI/CD and secrets exposure review.
Sources: LiteLLM incident post | LiteLLM root cause report | The Hacker News
Published: 2026-10-27 | Category: Supply Chain Security | ~4 min read
