LiteLLM 1.107.0 Incident: A Hands-On Triage Checklist for Python and Docker Deployments

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 litellm on 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.py and sitecustomize.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 like latest to 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.