Supply Chain Attack on LiteLLM: What Your Team Should Change Now

On October 21, someone published a poisoned build of LiteLLM, the open-source gateway a lot of teams use to route calls to OpenAI, Anthropic and other model providers. For about an hour and a half, pip install litellm could hand you version 1.107.0, a release that stole credentials and installed a remote code loader. The source code on GitHub was clean. The package wasn't.

That's a textbook supply chain attack: nobody hacked the businesses that got hurt. They trusted a dependency, and the dependency's release process was compromised. If your product touches AI, it's worth ten minutes: the fixes are cheap and the exposure is real.

TL;DR#

• A compromised release pipeline pushed malicious LiteLLM 1.107.0 to PyPI and Docker Hub on October 21, 2026. Previous versions are reported as safe.
• The malware ran on every Python start and targeted cloud keys, SSH keys, .env files and the AI provider keys stored in the LiteLLM proxy.
• Pinning versions by hash, delaying new releases, locking down outbound traffic and scoping secrets would have contained most of the damage.

What happened in the LiteLLM supply chain attack#

LiteLLM's own incident write-up lays out the timeline in UTC. An attacker holding several developers' GitHub CLI credentials used an owner-level token to switch off branch protection and change the private release workflow. The modified workflow then built from a lookalike repository the attacker controlled. A second stolen credential cleared the production approval gate.

Seven malicious wheels for litellm==1.107.0 went live on PyPI at 11:39 and were pulled at 13:23. The Docker tags v1.107.0, latest, main-latest and main-stable pointed at the poisoned image until 14:20.

What the payload did#

According to BleepingComputer, the attacker didn't touch LiteLLM's application code at all. They dropped three files (cook.pth, cook.py and sitecustomize.py) into Python's library folder. Python loads those automatically, so the malware ran whenever Python started, even if you only ran pip to check what was installed.

It went after cloud credentials, Kubernetes configs, CI/CD secrets, SSH keys, browser logins and the LiteLLM proxy database, which can hold keys for many model providers at once. Data was encrypted and sent to a lookalike domain, and a loader checked in hourly for more code.

Why this matters more than a typical package incident#

Three details make this worth a pause.

First, it's the second LiteLLM compromise in seven months. In March, attackers published bad versions after breaching a security scanner LiteLLM used in its own CI pipeline. Popular AI tooling is now a target in its own right.

Second, the maintainers had already hardened their process after March: private release repo, trusted publishing, immutable Docker tags, signed images. The attacker got around all of it by controlling the pipeline that does the signing. A valid signature told you the build came from LiteLLM's pipeline. It didn't tell you the pipeline was honest.

Third, the blast radius. BleepingComputer puts LiteLLM at roughly 92 million monthly PyPI downloads. An LLM gateway sits right where your most valuable secrets live, because its whole job is holding API keys and talking to the outside world.

Security firms flagged the release within six minutes. Automated pipelines install packages in seconds.

The technical breakdown: where each defense helps#

No single control stops a software supply chain attack. Each one narrows a different gap.

The trade-off nobody likes#

Pinning and cooldowns mean you get security patches a few days later. That's a real cost. The fix is a simple rule: routine upgrades wait, while a flagged security patch gets a human review and an expedited path. Tools like Renovate (minimumReleaseAge) and Dependabot (cooldown) can enforce the waiting period for you.

A safe install path looks roughly like this:

dev bumps version -> bot waits 5 days -> CI installs from hash-locked file
   -> image built and pinned by digest -> deploy to network with egress allowlist

What it means for businesses without a security team#

Most companies we talk to don't have a security engineer. They have one overworked developer and a product that quietly depends on hundreds of open-source packages.

The uncomfortable part: if you've added an AI feature in the last year, there's a fair chance something like LiteLLM is in your stack, maybe pulled in by another library. Chainguard notes that more than 2,000 packages depend on it. You may not know it's there.

The practical risk isn't only "an attacker reads our code." It's that one server holds your Stripe key, your database password, your cloud credentials and five model provider keys, and all of them leave together. Supply chain attack prevention, for a small team, mostly means making sure one bad package can't reach everything.

How to act on it: a checklist for this week#

1. Check exposure. Search lockfiles, requirements.txt and container manifests for litellm==1.107.0 and the affected Docker tags. Check transitive dependencies too.
2. If you were hit, don't run Python on the box first. LiteLLM's guidance is to isolate, rebuild from scratch and pin litellm==1.106.2 or another earlier version.
3. Rotate everything the host could reach. Cloud roles, provider keys in the proxy database, master keys, database passwords and anything in environment variables. Assume exfiltration happened if the host had internet access.
4. Hash-pin your dependencies. Generate a lockfile with hashes and make CI fail if it changes without review.
5. Add a release cooldown of a few days for routine upgrades.
6. Pin container images by digest. Stop deploying latest.
7. Restrict outbound traffic from production servers to the domains they actually need.
8. Split secrets by service. The AI gateway shouldn't hold your payment keys.
9. Treat CI credentials like production credentials. LiteLLM's write-up points to developer tokens leaking through logs as a suspected entry point.

How MagicMakers Lab approaches this#

When we build custom software or wire AI into an existing stack, dependency hygiene ships with the first commit: hash-locked installs, images pinned by digest, a scoped secret per service and outbound traffic limited to what each component needs. On Framico, where 200+ orders a day ship with zero manual steps, the automation touches several third-party systems, and keeping each integration's credentials separate is what lets one failure stay one failure. If you're unsure what's inside your own stack, that's the first thing we'd map.

Key takeaways#

• A supply chain attack hits you through software you trust, so your own code being clean isn't enough.
• Signed builds prove where a package came from, not that the build process was safe.
• Hash pinning plus a short cooldown would have kept most teams clear of LiteLLM 1.107.0.
• AI gateways concentrate secrets, so give them their own narrow credentials and network rules.
• If you installed the bad version, rebuild and rotate; cleaning in place isn't enough.

FAQ#

What is a supply chain attack?#

A supply chain attack compromises something you depend on, like an open-source package, a build tool or a vendor's update server, instead of attacking you directly. You install or update as normal and the malicious code arrives with it. The LiteLLM incident is a clear example: the package name and version looked legitimate, but the published build contained credential-stealing malware.

How do I know if I installed LiteLLM 1.107.0?#

Check your lockfiles, requirements.txt, Docker image tags and digests for version 1.107.0, including indirect dependencies. LiteLLM also lists indicator files in site-packages, such as cook.pth and sitecustomize.py. Inspect them without launching Python, since the malware runs on every Python start, even when you only run pip.

How can a small business prevent supply chain attacks?#

Pin dependencies with hashes, wait a few days before adopting new releases, pin container images by digest and limit which domains your servers can reach. Then split secrets so each service only holds what it needs. None of this needs a security team, and together these steps block or contain most package-level attacks.

Is it still safe to use LiteLLM?#

The maintainers say earlier versions were not affected and that customers on the private enterprise registry were not hit. Version 1.106.2 is the recommended recovery release. Whether to keep using it depends on your risk tolerance, but the bigger lesson applies to every dependency: pin, delay and scope, whichever gateway you use.

If you're not sure which open-source packages your product relies on, or where your API keys actually live, a short review usually answers both. We'll walk through your stack with you and point out the two or three changes that matter most. Book a free audit.

Sources#

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised (LiteLLM)
• LiteLLM release pipeline hacked to distribute info-stealer malware (BleepingComputer)
• LiteLLM attacked again: Malicious 1.107.0 wheels on PyPI and Docker Hub (Chainguard)