On 21 October 2026, a malicious LiteLLM 1.107.0 was published to PyPI and Docker registries for a few hours. It was built from a lookalike repository with compromised developer credentials and contained credential-stealing code. The official GitHub source tag was clean, and LiteLLM says private enterprise registry customers were not affected.
If you run LiteLLM as a gateway in front of model providers, here is a practical way to triage.
1. Check the exposure windows (UTC, 21 October)
- PyPI
litellm==1.107.0: 11:39 to 13:23 - Docker Hub tags
v1.107.0,latest,main-latest,main-stable: 11:46 to 14:20 - GitHub Container Registry images (
litellm,litellm-database,litellm-non_root): from 11:46 until unavailable by 13:51
Any unpinned install, image pull or CI build in those windows is a candidate.
2. Inventory and look for indicators
- Run
pip show litellmon hosts and in CI runners, and record image tags and digests. - In site-packages, look for
litellm-1.107.0.dist-info,cook.pth,cook.pyandsitecustomize.py. - An empty search does not prove a host is clean.
3. Rebuild, pin, rotate
- Do not upgrade in place. Python startup can execute the malicious files again, so rebuild images and environments from scratch.
- Pin
1.106.2(or any pre-incident release) and stop shipping floating tags likelatestto production. - Rotate model provider keys, LiteLLM master and virtual keys, database passwords and cloud roles the host could reach.
- Check logs and provider billing for unusual key use since 21 October.
4. Harden the pipeline
- Pin dependencies and verify image digests.
- Restrict who can approve releases.
- Keep secrets out of logs.
More detail: full LiteLLM compromise guide with FAQs
Written by the team at Affix Center, an IT services company in Lower Parel, Mumbai.
Top comments (0)