LiteLLM Supply Chain Attack: Was v1.107.0 in Your Stack?

A LiteLLM supply chain attack hit the open-source LLM gateway and Python SDK on 21 October 2026. According to LiteLLM's incident post, its release pipeline was compromised and pushed version 1.107.0 to PyPI and to its Docker registries. That version contained compiled malware that steals credentials and loads remote code execution tools. The bad artifacts have been removed, LiteLLM says all previous versions are safe, and enterprise customers using its private registry were not affected. If any of your services installed LiteLLM on 21 October, check them now.

Which LiteLLM versions and images were affected?

LiteLLM lists these compromised artifacts and exposure windows, all on 21 October 2026 (UTC):

The compromised image index on Docker Hub had the digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. The artifacts were built from an attacker-controlled lookalike repository, Berri-AI/litellm instead of BerriAI/litellm. LiteLLM's Director of Security later clarified that there is no official v1.107.0 source tag, and LiteLLM is skipping that version number.

How do I check if I am affected?

LiteLLM says you are affected if you installed an unpinned LiteLLM with pip between 11:39 and 13:23 UTC, or ran one of the Docker tags above between 11:46 and 14:20 UTC. Its checks:

• Run pip show litellm. If any environment started Python with litellm==1.107.0, treat that environment as compromised.
• If a container ran the image digest above, treat it as compromised.
• Search the filesystem for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Finding one confirms exposure; not finding one does not prove the environment is clean.

What to do if you ran LiteLLM 1.107.0

These steps come from LiteLLM's incident post, which credits them to LidorMachluf, who helped LiteLLM detect the incident.

1. Do not start with pip install. Any Python start in the affected environment runs cook.pth and sitecustomize.py again, and that includes running pip.
2. Remove the payload from the shell. Delete cook.pth, cook.py, sitecustomize.py and any matching __pycache__/cook*.pyc and sitecustomize*.pyc files from every affected site-packages directory.
3. Kill the detached Python daemon. It holds /tmp/remote_code_loader.lock.
4. Reinstall a clean version. Pin litellm==1.106.2. Rebuilding images and virtual environments from scratch is better.
5. Assume the theft succeeded. If 1.107.0 was ever installed on a host with outbound internet access, LiteLLM says to assume the exfiltration worked.
6. Rotate every secret the host could reach. In particular 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 in the environment of any process on the host.
7. Check for misuse. On AWS, look in CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of the role's credentials from outside your infrastructure.

How the LiteLLM attack happened

LiteLLM published a root cause analysis on 23 October and calls it the canonical record; it says some details in its earlier status updates turned out to be inaccurate or incomplete. The chain it describes:

1. A leaked key was never revoked. On 27 May 2026 a configuration file committed to a public LiteLLM repository contained the master key of an internal agent platform. The commit was overwritten, but the master key was not revoked.
2. That key exposed an owner's GitHub token. On 10 October the attacker used the master key to call the platform's API, which returned the GitHub CLI OAuth token of one of LiteLLM's two GitHub organisation owners. LiteLLM notes that GitHub CLI tokens are issued after two-factor authentication and are not subject to GitHub's re-authentication prompts for sensitive actions.
3. CI workflows leaked two more tokens. The same day, the attacker pushed throwaway branches whose workflows posted repository secrets to an attacker-controlled endpoint, collecting the GitHub CLI tokens of two maintainers, then deleted the workflow runs.
4. The release pipeline was repointed. On 21 October the attacker used the owner's token to override branch protection and point LiteLLM's release workflow at the lookalike repository. That week LiteLLM had relaxed its release rule so that any two engineers could trigger and approve a release; the attacker used one stolen token to trigger it and another to approve it, then deleted the run records.

The malicious wheels went live at 11:39 UTC. GitHub issue #47826, which identified the compromise, was opened at 12:06 UTC, and LiteLLM began incident response at 13:02 UTC. During the response LiteLLM locked its public registries to new releases and removed every member but one from its GitHub organisation, and it is revoking every token linked to its internal systems and vendor platforms.

Is it safe to update LiteLLM now?

On 24 October LiteLLM's Director of Security confirmed on the GitHub issue that every image then in its public registry is legitimate, including 1.103.7, 1.104.5, 1.105.3 and 1.106.2. New releases have since appeared on PyPI, including 1.106.3 on 24 October and 1.106.4 on 25 October. Pin an exact version in pip and pin Docker images by digest, so a moving tag such as main-latest cannot hand you a different build. LiteLLM's Director of Security also recommends blocking unexpected network egress from LiteLLM hosts, which limits what a malicious release could send out. Separately, LiteLLM's incident post says an embargoed fix for another vulnerability, already shipped to enterprise customers, has a disclosure date of 27 October, so watch its GitHub security advisories for that.

What to do next

Find every service that installs LiteLLM, including CI runners and AI features inside your storefront or apps, and check its version and install date. If anything ran 1.107.0, rotate the model provider keys and cloud credentials it could reach before you do anything else. Our ecommerce supply chain security checklist covers pinning, lockfiles and secret rotation, and the same week's Railway security breach is a reminder to keep that rotation runbook current. If you want an AI gateway or Shopify app backend reviewed or rebuilt, our Shopify app development team can help.

Related guide: LiteLLM alternatives: 5 LLM gateways compared.