The LiteLLM Compromise: Same Playbook, Bigger Prize

I've spent a good part of my career on both sides of this, breaking into environments and then helping teams keep people out. So when I wrote in December that Shai-Hulud was the start of something, I wasn't going out on a limb. When an attack works, attackers do it again, and they look for somewhere with better loot.

Since then we've had Glassworm in March and axios in April. Yesterday it was LiteLLM.

If you haven't come across it, LiteLLM is an open source gateway that sits between your applications and model providers like OpenAI, Anthropic and Bedrock. For a couple of hours on October 21, installing it from PyPI or pulling the latest Docker image got you a build that stole credentials and set up remote code execution.

What happened

The short version, from LiteLLM's own write-up: the attackers never touched the code on GitHub. The v1.107.0 source tag was clean. They built the bad release from a lookalike repo, Berri-AI/litellm instead of BerriAI/litellm, and pushed it out through LiteLLM's real release pipeline.

That took developer access, and they had it. They'd collected GitHub OAuth tokens belonging to LiteLLM developers. One belonged to an org owner and was used to switch off branch protection. Another got the release through the approval step. A third was used afterward to delete workflow logs. LiteLLM thinks the way in was an internal deployment reachable from the internet, probably through a vulnerability that had only recently been patched.

Speaking as someone who has done this kind of thing on red team engagements, none of it is exotic. Get the tokens, act as the developer, tidy up on the way out. It works because pipelines trust whoever holds the right credential.

Older versions weren't affected, and neither were Enterprise customers using LiteLLM's private registry. Nobody has been named as responsible yet, and the investigation is still going.

Why I'd pay attention to this one

Most supply chain incidents land a package on a laptop or a build server, and then the malware goes looking for secrets. LiteLLM is different because of what it is. An AI gateway's whole job is to hold credentials: provider API keys, master and virtual keys, a database password, often a cloud role. Get onto it and there's no need to go looking. It's all in one place.

The second thing is where the attack happened. Code review wouldn't have caught it, because the code was fine. The weak point was developer identity and how much the CI/CD pipeline trusts it. We flagged that in December, and it's where I expect most of these attacks to head from here.

The third is that plenty of teams don't know they run LiteLLM at all. It tends to arrive with an AI project, often set up quickly by a team outside security. If I asked most security leads today where it's running in their environment, I doubt many could tell me within the hour.

If you run LiteLLM, do this now

This follows LiteLLM's guidance, with a few notes of my own.

1. Find every copy. That means servers, containers, Kubernetes, CI runners and developer laptops. On each one, look for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py in site-packages, and check image digests against the ones LiteLLM published.
2. If a host looks affected, don't reach for pip first. The malicious files run again every time Python starts. Delete cook.pth, cook.py, sitecustomize.py and their __pycache__ files, then kill the background Python process holding /tmp/remote_code_loader.lock.
3. Don't try to clean it in place. Rebuild the image or virtual environment from scratch and pin to litellm==1.106.2 or an earlier release.
4. Rotate everything that host could reach: cloud IAM roles, every provider key in the proxy database, LiteLLM master and virtual keys, the database password, and anything sitting in environment variables.
5. Check whether those keys have been used. In AWS, look in CloudTrail for GetCallerIdentity calls from the instance role around install time, and for the same credentials turning up from outside your network.
6. Fix the habits that let it in. Pin versions and image digests, stop deploying latest, and give new releases a day or two before they reach production.

One thing I've learned the hard way: not finding the indicators doesn't mean you're clean. If a host pulled the bad release during the window, assume its credentials are gone and rotate them.

Where Mondoo fits

The first question in any incident like this is "where are we exposed?" It's usually the slowest one to answer. Someone ends up running pip show on box after box, or digging through container registries, while the clock runs.

Mondoo is built to answer that question fast. It continuously assesses developer workstations, repositories, container images, Kubernetes clusters and CI/CD pipelines, so an affected LiteLLM version or image shows up across the whole estate without anyone having to hunt for it. You see what's affected, why it matters and what to fix first. Policies for version pinning, dependency integrity and known-malicious packages mean the next bad release gets blocked instead of chased.

LiteLLM won't be the last. Attackers have worked out that release pipelines and developer tokens are a good way in, and AI tooling is where valuable credentials are piling up. The teams that get through the next one well will be the ones who already know what they're running.

Talk to us about preemptive exposure validation for your software supply chain →

Further reading

• Beyond Shai-Hulud: Why the Era of the Software Supply Chain Worm Has Just Begun (December 2025)
• Glassworm Proves It: The Supply Chain Worm Era Is No Longer Theoretical (March 2026)
• Axios Compromised: A Nation-State Supply Chain Attack (April 2026)
• npm Supply Chain Security in 2026 (May 2026)
• How Mondoo analyzes AI agent skills before you install them