LiteLLM 1.107.0 shipped a credential stealer and hourly RCE backdoor on PyPI and Docker Hub on Oct 21, 2026. Here's how to check, clean, and rotate your keys.
Vamsi Tallapudi
Manager, Architect Technology at Cognizant
LiteLLM pushed a backdoored release to PyPI and Docker Hub on October 21, 2026. If you ran pip install litellm==1.107.0 or pulled the latest, main-latest, or main-stable Docker tags that day, assume every credential on that machine is burned and start rotating now, before you finish reading this.
This is the part that should bother you more than the malware itself: LiteLLM is the proxy a lot of teams run specifically to avoid handing raw provider keys to every tool that calls an LLM. We said as much five days earlier, when OpenCode's Console breach burned OpenAI, Anthropic, and Google keys for 1.4% of its users: "run your own proxy like LiteLLM instead of letting a vendor hold your keys at rest" was the advice. Then the proxy got popped, and it didn't just leak the host it ran on. It went and queried its own Postgres table for every provider key it was holding on behalf of other people.
Attackers compromised LiteLLM's GitHub release pipeline using stolen GitHub CLI OAuth tokens from three of the project's engineers. LiteLLM's incident report says the tokens were likely pulled from logs of an internal LiteLLM deployment that had been exposed to the internet, so the attacker didn't need to breach PyPI or Docker Hub directly, just borrow credentials from inside.
With one compromised account, the attacker retargeted LiteLLM's private release workflow at a lookalike repository, Berri-AI/litellm (one hyphen different from the real BerriAI/litellm). They stacked ten extra commits with the malicious payload on top of the legitimate tag, used a second account to approve the run, and a third to delete the workflow logs afterward. The pipeline did exactly what it was told: it built, signed, and published the poisoned package as a legitimate release.
The malicious litellm==1.107.0 was live on PyPI from 11:39 to 13:23 UTC (about 104 minutes). The matching Docker images (v1.107.0, latest, main-latest, main-stable on both Docker Hub and GHCR) stayed up longer, from 11:46 to 14:20 UTC. Socket's security team put LiteLLM's reach at more than 92 million downloads a month, which is why a 104-minute window still mattered.
Every one of the seven compromised wheels dropped three extra files straight into the root of site-packages: cook.pth, cook.py, and sitecustomize.py. That's the clever part, and it's worse than a typical malicious import.
Python auto-executes .pth files and sitecustomize.py on every interpreter startup, in any script, not just when something imports LiteLLM. So the backdoor didn't need your code to call LiteLLM at all: it ran the moment you typed python, ran a test suite, or even ran pip itself to try to fix the problem.
sitecustomize.py also forked a detached background daemon. Once an hour, that daemon checked a dead-drop file hosted on GitHub for a command-and-control domain, then downloaded and executed whatever code was waiting there: a standing remote access channel, not a one-time grab.
The stealer, cook.py, went after pretty much everything a developer machine or CI runner tends to have lying around:
~/.aws/, environment variables, EC2/ECS instance metadata).env filesAnd then the part that makes this specifically an "AI gateway" incident rather than a generic infostealer: if you ran LiteLLM Proxy, the malware queried its own Postgres credentials table directly and pulled up to 500 stored upstream provider keys: OpenAI, Anthropic, Google, whatever your team had routed through it. A proxy's entire job is holding everyone else's keys in one place. That's exactly what made it worth more to steal than any single developer's laptop.
Everything got encrypted and POSTed over plain HTTP to http://www.litellm.dev/healthcheck, a lookalike domain registered October 13, 2026, just eight days before the attack, sitting behind Cloudflare to mask the real host. Wiz Research says the attacker started using the stolen credentials fast: between 16:20 and 17:01 UTC, about four and a half hours after exfiltration began, they were already validating AWS instance-role credentials pulled from compromised CI runners and Kubernetes nodes.
Run this before anything else, and don't pip install anything in a potentially infected environment to check, since that re-triggers the payload:
pip show litellm or grep your lockfiles and requirements.txt/pyproject.toml for 1.107.0.litellm/litellm:latest, main-latest, main-stable, or v1.107.0 from Docker Hub or ghcr.io/berriai/litellm between October 21, 11:46 and 14:20 UTC?site-packages directory (and container layer) for cook.pth, cook.py, and sitecustomize.py, plus their compiled .pyc versions under __pycache__./tmp/remote_code_loader.lock and /tmp/.pc_once_* marker files are host-level signs the backdoor ran.litellm.dev or www.litellm.dev from a box that shouldn't be talking to it is a compromise signal, even on hosts that never ran Python directly.If any of those come back positive, treat the host and every credential it touched as compromised. Don't try to "clean" it in place and move on.
Don't trust an in-place fix. The whole mechanism depends on files sitting in site-packages that run on every Python startup, including the pip install you'd use to "upgrade away" the problem. Rebuild instead:
/tmp/remote_code_loader.lock before you touch anything else, or it keeps phoning home while you work.cook.pth, cook.py, sitecustomize.py.litellm==1.106.2: the last version confirmed clean before 1.107.0. The release candidates 1.107.0rc1 and 1.107.0rc2 are also clean, if you need something newer than 1.106.2.Rotate from a machine you know is clean, not the infected one, since anything you type or copy there can be captured again.
Check provider usage dashboards for anomalous spend or requests you didn't make while you're at it. That's often the first sign a stolen key is already in use, the same runaway token burn we broke down in our guide to usage limits and cost.
Yes, and that's the uncomfortable context here. This is the second LiteLLM supply-chain attack in 2026. In March, a threat actor tracked as "TeamPCP" compromised LiteLLM's PyPI publishing credentials through a poisoned Trivy dependency used in the project's own CI security scanning, and pushed backdoored versions 1.82.7 and 1.82.8. That one was live for roughly 40 minutes before PyPI quarantined it. There's no evidence tying the October attack to TeamPCP: different method, same project, same category of damage.
Two serious compromises of the same release pipeline in seven months is not a coincidence you can wave away as bad luck. If you depend on LiteLLM as the one place that holds every provider key for your team, you're betting on a project whose GitHub release workflow has now been hijacked twice in a year, the same kind of trust assumption that broke down when an OpenAI model escaped its own sandbox earlier this year.
I'd still rather run my own proxy than scatter raw keys across a dozen tools: one compromised pipeline beats twenty. But "run your own proxy" only holds up if you actually isolate it, scope its keys with spend caps, and watch its egress traffic like you would any other service with privileged access. Treat your AI gateway like the high-value target it clearly is, because attackers already figured that out before most of us did.
New AI tools, automation workflows, and course drops — straight to your inbox. Join 2,400+ builders.
NVIDIA OpenShell sandboxes AI agents with kernel-level isolation and YAML policies. Here's how it works, how to install it, and what it still can't stop.
Claude Duet is Anthropic's proactive Opus 5.5 agent app, live as a US Pro/Max waitlist preview since Oct 21, 2026. Here's what it does and how it beats Muse and Dots.
Earshot is an open-source, CPU-only MCP server that gives Claude Code and other coding agents the ability to hear, score, and synthesize sound effects.
Comments