LiteLLM hacked again — your AI keys are the target

For the second time this year, the AI community's favorite open-source gateway has been poisoned. On October 21, 2026 at 11:39 (UTC), a malicious version of LiteLLM — release 1.107.0 — landed on PyPI, the default package registry for Python. It sat there for one hour and forty-one minutes before being quarantined at 13:20 (UTC). In that window, anyone who ran pip install litellm or pulled the latest Docker tag got a credential stealer along with their LLM proxy.

LiteLLM is not some obscure library. It's the de facto standard gateway for routing requests to 100+ language model providers — OpenAI, Anthropic, Bedrock, Azure, HuggingFace, you name it — through a single OpenAI-compatible interface. It has over 18,000 GitHub stars and is embedded in the CI/CD pipelines and production deployments of countless AI startups and enterprise teams. The people who install LiteLLM are exactly the people who hold the keys: API tokens for every major model provider, cloud credentials for AWS/Azure/GCP, GitHub access tokens, and browser-stored passwords. That's what the attackers came for.

How the attack worked

The technique was clever, and it exploited a quirk of Git that most developers don't think about. The legitimate LiteLLM repository lives at github.com/BerriAI/litellm. The attacker created a lookalike organization — github.com/Berri-AI/litellm (note the hyphen) — and pushed malicious commits there. Because Git shares fork objects across parent repositories, those commits became visible in the legitimate repo's commit history even though the lookalike repo itself was hidden from GitHub's interface.

Between 08:56 and 10:46 (UTC) on October 21, the attacker pushed 10 commits using the email [email protected]. The first three added three files: cook.pth, cook.py, and sitecustomize.py. Four more bumped the version to 1.107.0. After a 39-minute pause, two commits refined the payload and added a critical data = "cook" directive to pyproject.toml — the line that told the build tool to bundle the malware into the wheel file. A final commit, unsigned and from a different email, added COPY cook ./cook to the Dockerfiles, ensuring the trojan also shipped in container images.

The payload itself is a two-stage implant:

The exfiltration domain www.litellm.dev is an attacker-controlled lookalike, impersonating LiteLLM's infrastructure. The second-stage backdoor was never observed active — the dead-drop file was never populated, and the GitHub repo was taken down at 13:30 (UTC). But the credential stealer ran immediately on install, no user interaction required.

Affected Docker tags included v1.107.0, latest, main-latest, and main-stable on both GHCR and Docker Hub. The most recent safe version is v1.106.2.

Déjà vu — this is the second time

This is not LiteLLM's first supply chain compromise. In March 2026, versions 1.82.7 and 1.82.8 were poisoned by the threat group TeamPCP, which had earlier compromised Aqua Security's Trivy scanner and used stolen maintainer credentials to push malicious releases. That attack harvested AWS/GCP/Azure tokens, SSH keys, and Kubernetes credentials, and was available on PyPI for roughly three hours before quarantine. Mercor, an AI hiring platform, later confirmed it was "one of thousands" affected, and Meta suspended its partnership with the company while OpenAI investigated whether training data had been exposed.

The October attack is different in technique — no stolen credentials, instead a Git fork-object injection — but identical in target and objective. The attackers know that LiteLLM is a high-leverage chokepoint. Whoever compromises LiteLLM doesn't just hack one company; they hack every company that trusts LiteLLM with their API keys.

Why this matters — and why it should scare you

The obvious takeaway is "rotate your keys if you installed LiteLLM between 11:39 and 13:20 (UTC) on October 21." That's necessary but insufficient. The deeper problem is structural.

AI infrastructure is consolidating around a small number of open-source chokepoints — LiteLLM for routing, vLLM for inference, LangChain for orchestration, HuggingFace for model distribution. Each one is a single point of failure that, if compromised, gives attackers access to the keys and data of thousands of organizations simultaneously. Traditional security thinking treats supply chain risk as a probability problem: what are the odds this package gets hijacked? The new reality is that these packages are targets, not accident victims. Attackers don't randomly poison packages — they pick the ones that sit at the convergence of the most credentials.

LiteLLM is the perfect example. It's designed to hold your API keys. That's its job. You give it your OpenAI key, your Anthropic key, your AWS Bedrock credentials, and it routes traffic and tracks spend. A supply chain attack on LiteLLM isn't a theoretical risk — it's the most direct path to stealing the crown jewels of every AI team on the planet. The fact that it has now happened twice in seven months tells you everything about the incentive structure.

The 101-minute exposure window sounds short, but it's more than enough. CI/CD pipelines run pip install constantly. Docker builds pull latest tags on every rebuild. Automated dependency bots open PRs within minutes of a new release. PyPI doesn't publish real-time download counts for individual hours, but LiteLLM does millions of downloads per week. Even a conservative estimate puts the number of compromised installs in the thousands — and each one represents an organization whose API keys, cloud credentials, and GitHub tokens are now in an attacker's collection.

The uncomfortable questions

LiteLLM's maintainers have now presided over two supply chain compromises in the same year. The March attack was blamed on stolen credentials obtained through a third-party tool (Trivy). The October attack used a completely different technique — Git fork-object injection — that bypasses traditional package signing and 2FA entirely. This raises a question that the AI community has been slow to ask: are the maintainers of our most critical infrastructure actually funded and staffed to defend against determined, well-resourced attackers?

LiteLLM is a small team (1-10 employees according to RivalSense) maintaining a project used by tens of thousands of organizations. The economics of open-source security are well-known and well-broken: the burden falls on volunteers and tiny startups, while the benefit accrues to billion-dollar companies. The difference now is that the stakes have changed. When Log4Shell hit, it affected Java applications. When LiteLLM gets poisoned, it affects every AI company's model API keys — the literal fuel of their business.

There's also a detection problem. The malicious cook.py file is 22,252 bytes of obfuscated Python. It decrypts itself at runtime, exfiltrates over HTTPS to a lookalike domain, and writes a run-once marker to /tmp to avoid duplicate collection. Standard antivirus and endpoint detection tools are unlikely to flag it. The only reason we know about it at all is that Wiz and JFrog researchers caught it quickly — but that's a bet on researcher attention, not a defensible security posture.

What to do right now

If you or your team installed LiteLLM 1.107.0 or pulled affected Docker tags between 11:39 and 13:20 (UTC) on October 21, 2026:

1. Rotate every credential on the affected machine — OpenAI, Anthropic, AWS, Azure, GCP API keys; GitHub tokens; browser-saved passwords; SSH keys. Assume they're all compromised.
2. Downgrade to v1.106.2 or upgrade to any version after 1.107.0 once a clean release is available.
3. Check for persistence artifacts: cook.pth, cook.py, sitecustomize.py in your site-packages root, and the marker file /tmp/.pc_once_72129118c59f5636c0bb.
4. Pin your dependencies. Don't use latest Docker tags in production. Don't run pip install without version pins. The 101-minute window only hurts you if your infrastructure automatically grabs new releases.

What to watch next

• Whether the second-stage payload activates: The sitecustomize.py backdoor was never armed, but the attacker still controls the dead-drop mechanism. If the GitHub repo or a similar dead drop gets repopulated, already-compromised machines could download and execute arbitrary code.
• Who got hit: Wiz and JFrog have IOCs. Expect incident reports from companies that ran un-pinned CI/CD pipelines during the window. The March attack eventually implicated Mercor and froze Meta's work with them — this one could have similar fallout.
• Whether LiteLLM implements real supply chain hardening: Two attacks in one year should force sigstore signing, provenance verification, mandatory multi-party release approval, and a security audit. If the next release doesn't include these, the project has a structural problem, not a bad luck problem.
• The next chokepoint: LiteLLM is the most-targeted AI gateway today, but it's not the only one. vLLM, Ollama, and LangChain have similar trust profiles. Attackers go where the keys are — and right now, the keys are concentrated in a handful of open-source projects with minimal security budgets.

The AI industry spent 2026 talking about alignment, model safety, and existential risk. Meanwhile, the mundane work of securing the software supply chain that actually delivers AI to users got hacked — twice. The models are getting smarter. The infrastructure holding their keys is not.