LiteLLM Breached Again: Malicious Update Stole AI, Cloud Keys

For roughly two and a half hours on October 21, anyone who installed the AI library LiteLLM's latest update, or pulled its official Docker image, picked up a working credential stealer along with their code. No warning, no changelog note about malware — just a routine update that quietly started harvesting cloud and AI API keys the moment it ran.

What actually got poisoned

LiteLLM is a popular open-source gateway that lets developers talk to more than a hundred different AI models, OpenAI, Anthropic, Google Gemini and others, through one consistent interface instead of rewriting code for each provider. That convenience is exactly why thousands of AI apps and internal tools depend on it.

On October 21, version 1.107.0 showed up on PyPI (the official index Python developers use to install packages) and on Docker Hub (where ready-to-run container images are hosted). According to researchers at Chainguard and Datadog Security Labs, the code sitting on GitHub was untouched and clean. The problem was in the pre-built packages themselves: all seven distributed "wheels" (Python's packaged install format) carried a credential stealer that ran automatically at startup, plus a loader that reached out for additional malicious code every hour.

The compromised Docker tags, including v1.107.0, latest, main-latest and main-stable, pointed at the bad image for a window of a few hours before maintainers pulled it and repointed everything to a verified clean build. The last known-safe version is 1.106.2.

Why this is the second time this year

This isn't LiteLLM's first bad month. Back in March 2026, attackers stole a maintainer's PyPI publishing token, reportedly after compromising a security scanner called Trivy that LiteLLM's build pipeline used without pinning to a specific version, and used it to push malicious versions 1.82.7 and 1.82.8. That incident alone is estimated to have exposed credentials belonging to roughly 2,500 organizations, some of which security researchers say are still valid months later because nobody rotated them.

• March 2026: stolen publishing token used to push malicious versions directly to PyPI, GitHub source untouched
• October 2026: malicious code baked into the pre-built wheels and Docker images rather than the source
• Both incidents targeted the same thing: cloud keys, SSH keys and CI/CD secrets sitting on developer machines and build servers

Two separate compromises of the same widely-used AI library inside a single year says something uncomfortable about how fragile the software supply chain around AI tooling still is.

If you installed LiteLLM 1.107.0 or ran one of the flagged Docker images between October 21's release and its removal, the safe assumption is that your system was compromised, not that it probably wasn't.

What this means if you're building AI products out of India

LiteLLM shows up constantly in Indian AI stacks, from Bengaluru and Gurugram startups wiring together chatbots and copilots on a budget, to larger companies using it to route traffic between OpenAI and Anthropic depending on cost and latency. A lot of these teams run lean, with a handful of engineers managing their own CI/CD pipelines, which is precisely the setup a credential stealer like this one is built to exploit.

If an Indian company's AWS keys, database credentials or customer-facing AI API keys walked out the door in this window, that isn't just an engineering embarrassment. Under the Digital Personal Data Protection Act, any resulting exposure of personal data would trigger breach-notification obligations to the Data Protection Board, on top of whatever damage control the company has to do with its cloud provider. The Trivy-token root cause from March is also a reminder that "we only use trusted tools" doesn't help much when one of those trusted tools gets quietly compromised upstream.

The practical takeaway

Security researchers are converging on a fairly short list of things to actually do:

1. Check whether you installed version 1.107.0 or pulled an affected Docker tag on October 21
2. If so, remove the planted files, commonly named cook.pth, cook.py and sitecustomize.py, from your Python site-packages directory
3. Pin back to 1.106.2 until a verified clean release is confirmed
4. Rotate every credential that touched an affected machine, assuming it's burned rather than hoping it wasn't

None of this is exotic advice, and that's sort of the point. The fix is boring, routine hygiene; the problem is that most teams only do it after finding out they were exposed rather than as a standing habit. A library this embedded in the AI boom getting hit twice in seven months is a reasonable moment to stop treating "it's open-source and widely used" as a proxy for "it's safe," and start treating every dependency update, however small, as something worth a second look before it hits production.