LiteLLM Compromise: 1.107.0 Was Live About 2 Hours on PyPI. What to Check

The LiteLLM compromise hit on Wednesday, October 21, 2026: a poisoned version 1.107.0 of the popular AI-gateway library went out on PyPI and as official Docker images, carrying malware built to steal credentials. LiteLLM says the bad PyPI package was live for about two hours. If you installed or pulled LiteLLM that morning, treat the machine as exposed until you have checked.

Where it stands: In its update posted at 20:30 UTC on October 21, LiteLLM said the incident was contained, the affected releases had been pulled and every earlier version was safe. Its investigation into how the attacker got in was still open.

LiteLLM is a Python library and proxy that lets developers send requests to many AI model providers through one interface. That design means a single LiteLLM deployment often holds API keys for several providers at once, which is exactly what the malware went looking for.

What happened in the LiteLLM compromise?

An attacker got control of LiteLLM’s release process and used it to publish a tampered build. LiteLLM’s own write-up says its pipeline pushed 1.107.0 to Docker and PyPI, and that the build contained compiled malware that both steals credentials and loads tools for running remote code.

The source code on GitHub was not the problem. LiteLLM says its official 1.107.0 tag does not contain the malicious files; the poisoned packages were built from a lookalike repository named Berri-AI/litellm, one hyphen away from the real BerriAI/litellm.

Security firm Aikido, which analyzed the package, titled its report “LiteLLM compromised again.” LiteLLM itself refers to a prior incident in March, after which it says it hardened its release pipeline.

When was the bad version available?

For a few hours on the morning of October 21, UTC, with different windows for each distribution channel. These times come from LiteLLM’s incident post and the public GitHub issue that tracked the response.

According to the reporter who opened the GitHub issue, PyPI’s record of the upload runs from 11:39:51 until 11:40:13 UTC. Aikido later noted that PyPI had quarantined the version. LiteLLM says the last Docker Hub tags were removed or repointed to clean images at 14:20 UTC.

What did the LiteLLM malware try to steal?

Credentials, broadly: cloud keys, AI tool logins and the provider API keys LiteLLM stores. TechCrunch, summarizing the incident, said the code included an information stealer aimed at cloud, password and AI service credentials, plus a remote access trojan that could let attackers run commands.

Aikido’s analysis lists configuration and credential files for a long roster of AI coding tools, including Claude Code, Cursor, GitHub Copilot, Gemini CLI and Codex CLI. It also says the malware read LiteLLM’s own database, including the table holding stored API keys for every provider.

That last point is why this matters beyond one host. A LiteLLM proxy can be the one place a team keeps every model key it owns.

Am I affected by the LiteLLM compromise?

You are, by LiteLLM’s definition, if you installed an unpinned LiteLLM via pip during the PyPI window, or ran one of the four affected Docker tags during the Docker window. Pinned installs of earlier versions were not touched.

LiteLLM says enterprise customers pulling from its private registry were not affected; it says that registry was not compromised.

This is a Python supply-chain incident. It did not involve npm or Node.js, and TechCrunch noted that the incidents of that day were unrelated to each other. For the rest of that Wednesday, see our October 21 cyberattacks roundup.

How do I check a system for the bad LiteLLM release?

Start without running Python in the suspect environment. LiteLLM warns that any Python start there, including running pip, re-triggers the malicious startup files.

1. Check the installed version. LiteLLM suggests pip show litellm; if an environment ever started Python with 1.107.0, treat it as compromised. Because pip itself starts Python, check lockfiles, build logs or a plain listing of the site-packages folder first.
2. Check containers. Any container that ran the affected tags in the window, or the compromised image digest LiteLLM published, should be treated as compromised.
3. Look for the markers. LiteLLM names a litellm-1.107.0.dist-info folder, cook.pth and sitecustomize.py. Finding one confirms exposure; finding none proves nothing.
4. Rebuild, do not patch in place. LiteLLM recommends reinstalling pinned to 1.106.2 and says rebuilding images and virtual environments from scratch is better.

Which keys should I rotate?

Everything the affected host could reach. LiteLLM’s guidance is blunt: any machine that had the bad release and could reach the internet should be assumed to have leaked its secrets.

• The cloud IAM role of the instance or task.
• Every provider key stored in the LiteLLM proxy database, plus master and virtual keys.
• The database password in DATABASE_URL.
• Any secret present in the environment of any process on that host.

LiteLLM also suggests checking AWS CloudTrail for identity lookups by the instance role around install time, and then for that role being used from outside your own infrastructure. Our guide to protecting API keys and tokens covers rotation habits that make this kind of cleanup faster.

How did the attacker get into LiteLLM’s pipeline?

LiteLLM says the attacker held three sets of developer GitHub CLI credentials, used one belonging to an organization owner to override branch protections, and ran the release workflow against the lookalike repository.

LiteLLM believes those tokens came from logs in an internal LiteLLM deployment that was exposed to the internet, and it says it observed cases where Claude Code embedded a user’s GitHub CLI token in a response body that could then be logged. LiteLLM adds that it has not yet confirmed how the attacker reached that internal deployment, and suspects a recently patched vulnerability.

Those are LiteLLM’s preliminary findings, posted the same day. LiteLLM said it would update the post every two hours as its investigation continued.

Frequently Asked Questions

Which LiteLLM version was compromised?

Version 1.107.0, published on October 21, 2026 to PyPI, Docker Hub and the GitHub Container Registry. LiteLLM says all earlier versions are safe and recommends pinning to 1.106.2.

How do I know if I installed the bad LiteLLM release?

Run pip show litellm in each environment, check whether any container ran the affected 1.107.0 or latest-style tags during the windows LiteLLM published, and look for the files LiteLLM named, such as cook.pth and sitecustomize.py. Not finding them does not prove a system is clean.

Is LiteLLM an npm or Node.js package?

No. LiteLLM is a Python project. The malicious release went out as Python wheels on PyPI and as Docker images, not through npm. It was unrelated to the Node.js security release the same day.

What should I rotate after the LiteLLM compromise?

LiteLLM lists the cloud role the host used, every provider API key stored in the LiteLLM proxy database, the master and virtual keys, the database password, and any secret in the environment of any process on that host.

Were LiteLLM enterprise customers affected?

LiteLLM says customers running its private enterprise release were not impacted. The bad builds went out through the public PyPI, Docker Hub and GHCR channels.

Sources

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised — LiteLLM (Krrish Dholakia, Ishaan Jaffer, Oliver Jensen, Nate Armstrong), October 21, 2026 (last updated 20:30 UTC)
• LiteLLM compromised again: infostealer and RAT found in version 1.107.0 — Aikido Security (Ilyas Makari), October 21, 2026
• [SECURITY] litellm 1.107.0 compromised (PyPI removed; Docker latest/main-stable removed) — GitHub issue #47826 on BerriAI/litellm (opened by LidorMachluf), October 21, 2026
• The internet is having a very bad cybersecurity day — TechCrunch (Sarah Perez), October 21, 2026

This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.