LiteLLM Got Poisoned Again: Your AI Gateway Holds Every Key You Own

I'm almost a week late on this one, and I'm writing it anyway, because if you run LiteLLM and haven't checked yet, this is your sign. On October 21, a malicious LiteLLM 1.107.0 was published to PyPI and to LiteLLM's official Docker images. It's the project's second supply chain compromise this year.

Why LiteLLM Is Such a Good Target

LiteLLM is the plumbing a lot of companies use to talk to AI models. It's an open-source gateway that sits in front of OpenAI, Anthropic, Google, and everybody else, so your apps call one API and LiteLLM handles the rest. Which means a LiteLLM server holds the API keys for every model provider you use, plus whatever cloud credentials it runs with.

If you were an attacker and could pick one box in an AI stack to own, you'd pick that one.

What Happened

According to Datadog Security Labs' analysis, the attackers used stolen GitHub CLI OAuth tokens from three LiteLLM engineers to run the project's private release workflow against a lookalike fork, Berri-AI/litellm. The real one is BerriAI/litellm. One hyphen. How the tokens were stolen isn't known yet.

The application code wasn't changed. The attackers added three files to the install packages: cook.pth, cook.py, and sitecustomize.py. That's the clever, nasty part. Python runs .pth files and sitecustomize.py every time the interpreter starts. So the malware ran in any Python process in that environment, even if nothing ever imported LiteLLM. Running pip to uninstall it would trigger it again.

What it went after, per BleepingComputer and Datadog:

• Cloud credentials: AWS, Azure, Google Cloud (including instance metadata), Kubernetes, Docker, Vault, Terraform
• Developer secrets: SSH, GPG, and TLS keys, Git, GitHub, npm, and PyPI tokens, .env files, shell history
• AI credentials: model provider API keys and sessions for coding tools, plus the upstream provider keys stored in LiteLLM's own database
• Browser data: saved passwords and cookies

Everything got encrypted and shipped to litellm[.]dev, another lookalike. A second script checked a GitHub-hosted pointer every hour for more code to run. Datadog says it only held test values and they saw no second stage, which is good news, but it was built for it.

The exposure window was short: roughly 11:39 to 13:23 UTC on PyPI and up to about 14:20 UTC on Docker Hub. But "latest," "main-latest," and "main-stable" Docker tags were affected, and those are exactly the tags that auto-updating deployments pull.

Credit Where It's Due

The LiteLLM maintainers and PyPI moved fast: the package was quarantined in under two hours, the images were pulled, and the maintainers published a post-mortem with affected artifacts and timelines. Datadog published detailed IOCs. That's how a response should look. Supply chain attacks hit everyone who ships software, and nobody's immune to a stolen token.

What To Do If You Run LiteLLM

• Check for 1.107.0 in every environment, image, and lockfile. If you pulled latest, main-latest, or main-stable on October 21, assume you're affected until proven otherwise.
• Inspect without starting Python. Look for cook.pth, cook.py, and sitecustomize.py in site-packages from a shell, not from a Python tool.
• Rebuild, don't clean. Removing the package directory doesn't remove the startup files. Rebuild from a clean image and pin to 1.106.2 or a later verified release.
• Rotate everything that environment could reach: model provider keys, cloud credentials, Git and registry tokens, SSH keys. Do it from a clean machine.
• Review logs for use of those credentials since October 21.

The Bigger Lesson

• Pin versions and digests. Floating tags like latest turn someone else's bad afternoon into your incident.
• Treat developer CLI tokens like production credentials. That's what they are.
• Control egress from AI infrastructure. A gateway that only talks to the model providers you approved can't phone home to a lookalike domain. Inspect and restrict what leaves those servers.
• Shrink the blast radius. The gateway needs provider keys. It doesn't need broad cloud admin rights.

Bottom Line

AI gateways concentrate your most valuable secrets in one place, which makes them the supply chain target of the year. Pin what you pull, limit what the box can reach, and assume that anything holding every API key you own will eventually get a visit.

Sources: Datadog Security Labs analysis, BleepingComputer, and SecurityWeek