LiteLLM Was Poisoned: What the AI Supply Chain Attack Means for Your Projects

On October 21, 2026, a malicious version of LiteLLM, the popular Python library teams use as a single gateway to OpenAI, Anthropic, Bedrock and dozens of other model providers, was published to PyPI and Docker Hub. Version 1.107.0 looked like a normal release. It was a credential stealer.

The bad release was live for roughly two hours, but Wiz counted about 49,000 downloads in that window. It is also the second time this year LiteLLM's release process has been hit. If you build anything with LLMs, this one is worth ten minutes of your time.

What happened

According to LiteLLM's own incident report, its release pipeline was compromised and the published 1.107.0 packages contained compiled malware. The source code tag on GitHub was clean; only the built artifacts were poisoned. StepSecurity traced the build to a lookalike GitHub repository rather than the real one.

Affected:

• All seven litellm==1.107.0 wheels on PyPI
• The Docker images for v1.107.0, and the latest, main-latest and main-stable tags while they pointed to it

Not affected: 1.106.2, 1.107.0rc1 and 1.107.0rc2.

Why it was so dangerous: it ran without being imported

Most people assume a malicious package can only hurt them when their code imports it. This one did not wait. Each wheel dropped three files into site-packages: cook.pth, cook.py and sitecustomize.py. Python executes .pth files and sitecustomize every time the interpreter starts, so any Python process in that environment ran the payload: your app, your tests, a one-off script, even pip itself.

Microsoft and Datadog describe what it did next: collect cloud and AI credentials from the machine and set up a loader that fetches and runs remote code every hour. On a machine that runs an AI gateway, that is the worst possible place to land: those machines exist to hold API keys for every model provider the company uses.

Check your systems now

1. Find it. Run pip show litellm in every environment and image, and search your lockfiles and CI logs for 1.107.0. Check Docker hosts for the tags listed above.
2. Remove it. Delete cook.pth, cook.py and any unexpected sitecustomize.py from site-packages, then pin litellm==1.106.2. Rebuilding the environment or image from scratch is safer than cleaning it.
3. Rotate every secret that machine could read, and do it from a different, clean machine: model provider keys, cloud credentials, database passwords, CI tokens.
4. Audit usage of those credentials from October 21 onward: unusual API spend, new cloud resources, logins from unknown addresses.

Five habits that limit the damage next time

You cannot audit every package you install. You can make sure a single poisoned release has a hard time reaching production, and that it finds little to steal if it does.

1. Pin exact versions and install from a lockfile

A version range like litellm>=1.100 or a latest image tag means you accept whatever was published five minutes ago. Pin exact versions (== in requirements.txt, a committed package-lock.json with npm ci, an image digest instead of a tag) so nothing changes until you change it.

2. Pin hashes, not only versions

A version number is a name; a hash is the content. With pip install --require-hashes (or lockfiles from pip-tools, uv or Poetry) the installer refuses a file whose hash does not match the one you reviewed. Pinned hashes would not have stopped someone who chose to upgrade to 1.107.0, but they stop silent swaps of files you already trust.

3. Let new releases age before you take them

Most poisoned releases are caught within hours or days. Giving new versions a short cooling-off period before they reach your projects costs you almost nothing and would have skipped this incident entirely. Dependabot's cooldown option and uv's exclude-newer setting do exactly this. On my own projects Dependabot opens update PRs once a month, grouped, and every PR has to pass the build before it is merged, so a release published this morning never reaches production this afternoon.

4. Give each machine only the keys it needs

The malware stole whatever it could find. An AI gateway with one shared master key per provider, plus cloud admin credentials in its environment, hands everything over at once. Use separate keys per environment and per service, scope them as narrowly as the provider allows, set spending limits, and keep build machines free of production secrets.

5. Watch for the things that should never change

New .pth or sitecustomize.py files in an environment, unexpected outbound connections from a build job, a dependency that suddenly ships compiled code: these are cheap to monitor and rarely legitimate. Tools such as Socket, StepSecurity's Harden-Runner or a simple egress allowlist on CI catch exactly this kind of behaviour.

The bigger picture

AI tooling has become one of the most attractive targets in the software supply chain. The libraries are young and move fast, teams install them in a hurry, and they sit next to the most valuable secrets a company has. That combination will not go away. The good news is that none of the habits above are AI-specific or expensive: they are the same boring dependency hygiene that protects any project, applied to the part of the stack that is changing the fastest.

Sources

• LiteLLM: Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
• LiteLLM: The attack chain behind the v1.107.0 release
• Microsoft Security: Inside the LiteLLM 1.107.0 supply chain compromise
• Datadog Security Labs: LiteLLM supply chain compromise
• Wiz: LiteLLM Compromised, Steals Credentials
• StepSecurity: litellm 1.107.0 Compromised on PyPI