# LiteLLM 1.107.0 Malware: What Happened and What to Do

> A poisoned LiteLLM 1.107.0 hit PyPI and Docker on October 21, 2026 and stole credentials. Who is affected, how the pipeline was beaten, what to rotate.

- Author: Nitish Garg, Founder & CEO, CellCog
- Published: 2026-10-22
- Canonical (HTML): https://cellcog.ai/blog/litellm-1-107-0-malware/
- Section: Guides / Trust, permissions & security
- Publisher: CellCog (https://cellcog.ai), the AI employee platform. Blog index for agents: https://cellcog.ai/blog/llms.txt

## Key points

- A malicious litellm 1.107.0 was on PyPI from 11:39 to 13:23 UTC on October 21, 2026, and in four Docker Hub tags until 14:20 UTC.
- The official source was never changed: the release workflow was pointed at a lookalike repository, Berri-AI/litellm, and signed what it built.
- The wheels ran a credential stealer on every Python start, pip included, and planted an hourly remote-code loader.
- LiteLLM traces the three stolen GitHub CLI tokens to logs of its own internet-exposed LiteLLM deployment.
- Affected users should remove the hooks before running Python, pin litellm 1.106.2 and rotate every credential the host could reach.

## At a glance

- **Which LiteLLM version was malicious?** litellm 1.107.0 on PyPI, and the Docker tags v1.107.0, latest, main-latest and main-stable during the compromise window on October 21, 2026.
- **Am I affected?** Yes if an unpinned install pulled 1.107.0 between 11:39 and 13:23 UTC, or a container started from an affected tag before it was removed. Enterprise registry customers were not affected.
- **What should I pin?** litellm 1.106.2, after removing the malicious files, or rebuild the environment from scratch.

**A poisoned LiteLLM release, version 1.107.0, sat on PyPI from 11:39 to 13:23 UTC on October 21, 2026, about an hour and 44 minutes, and in the project's Docker images for two and a half hours. It ran a credential stealer every time Python started. LiteLLM says the attacker got in through its own internal LiteLLM deployment, where request logs held developers' GitHub CLI tokens.**

The official source code was never changed. The attacker pointed LiteLLM's release workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and the pipeline signed and published what it built. In LiteLLM's words: "The attacker had to compromise multiple independent security controls to be successful." This is the project's second release compromise this year: "After the prior incident in March, we meaningfully hardened our CI release pipeline."

## Who is affected

LiteLLM's [incident report](https://docs.litellm.ai/blog/security-incident-oct-21-2026) draws the line by artifact and time. "Customers running the private enterprise release of LiteLLM were not impacted."

*Table: Compromised LiteLLM artifacts and exposure windows on October 21, 2026, from LiteLLM's incident report*

| Artifact | Tags | Compromised (UTC) |
|---|---|---|
| PyPI | litellm==1.107.0, all seven wheels | 11:39:51 to 13:23 |
| Docker Hub | v1.107.0, latest, main-latest, main-stable | 11:46:56 to 14:20 |
| GHCR | v1.107.0, latest, main-latest, main-stable | 11:46:56 to 13:51 |
| Private enterprise registry | Embargoed release | Not affected |

You are affected if an unpinned pip install pulled 1.107.0 in that window, or if a container started from one of those tags. On October 22, PyPI lists 1.106.2 as the latest version; 1.107.0 is gone.

## What the malware did

The report that caught it, [GitHub issue #47826](https://github.com/BerriAI/litellm/issues/47826) by Lidor Machluf, opened at 12:06 UTC, lays out two startup hooks inside the wheels:

- **cook.pth and cook.py.** A .pth file runs on every start of that Python environment, pip included. It collects saved browser passwords and cookies, SSH keys and shell histories, AWS, Azure, Google Cloud, Kubernetes, Docker and GitHub CLI credentials, and cloud instance credentials. The data is encrypted and posted to litellm.dev, a domain registered on October 13 that is not the project's own.
- **sitecustomize.py.** It forks a background process that checks a GitHub file every hour for a domain, then downloads code from that domain and runs it. The issue reports the file empty since October 20, so this stage was dormant, but the operator can re-arm it with one commit.

![Animation: a site-packages panel holds an amber cook.pth file; three rows, Python start: pip, your app and again, light up in turn, and each sends an amber dot to a box labelled litellm.dev, not the project's domain](https://cellcog.ai/blog/media/litellm-1-107-0-malware/lite-every-python-start.svg)
*cook.pth runs on every Python start, pip included, and each start sends keys out*

## How the release pipeline was beaten

LiteLLM's normal flow already had the controls most projects are told to add: releases built in a private repository, a qualified commit, Trusted Publishers on PyPI, immutable Docker tags, signed images, and a publishing account locked to one laptop in the office. The timeline shows each one sidestepped with a stolen credential.

![Animation: two source boxes, BerriAI/litellm and the lookalike Berri-AI/litellm, feed a Release workflow box with three padlocks labelled Branch protection, Approval and Logs; three amber keys labelled Token 1, 2 and 3 open each padlock, the input line swings to the lookalike, and an amber parcel travels to PyPI 1.107.0](https://cellcog.ai/blog/media/litellm-1-107-0-malware/lite-lookalike-source.svg)
*Three stolen tokens opened the locks; the build came from the lookalike repository*

*Table: How each LiteLLM release control was bypassed on October 21, 2026, from LiteLLM's timeline (UTC)*

| Time | Control | What happened |
|---|---|---|
| Monday | Release permissions | Temporarily widened so two engineers could publish daily backports |
| 10:08:29 | Branch protection | Rejected an unauthorized change to the release workflow |
| 10:08:34 | Branch protection | An organization owner's token overrode it and force-pushed the change |
| 10:46:39 | Source of the build | A staging run built from the lookalike Berri-AI/litellm |
| 11:11:18 | Production approval | A second developer's credential approved the release |
| 11:53:49 | Workflow logs | A third developer's credential deleted the run records |

## Where the tokens came from

The attacker held three developers' GitHub CLI tokens. LiteLLM traces them to its own internal LiteLLM deployment, which was reachable from the public internet and carried an unexpected, innocuously named user account. Its explanation of how tokens got into that deployment's logs names a coding agent: in specific situations Claude Code embeds a user's GitHub CLI OAuth token into a response body, and where response bodies are logged, "these tokens may appear in LiteLLM logs."

LiteLLM has not confirmed how the attacker got into the deployment; it suspects "a recently patched vulnerability." It also says it is distributing an embargoed fix to enterprise customers for a vulnerability whose disclosure is scheduled for October 27.

## What to do if you ran it

From LiteLLM's report and the issue:

- **Do not start with pip.** Any Python start in the affected environment runs the hooks again. Delete cook.pth, cook.py, sitecustomize.py and their cached .pyc files from every affected site-packages first, and kill the detached Python process holding /tmp/remote_code_loader.lock.
- **Reinstall pinned** to litellm==1.106.2, or better, rebuild images and virtual environments from scratch.
- **Assume the theft worked.** "If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded."
- **Rotate everything the host could reach:** the instance or task IAM role, every provider 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 the host.

## The lesson for anyone running agents

Two parts of this chain are about agents, not packaging. A gateway that logs full response bodies becomes a store of whatever credentials the agents behind it print, and a coding agent with a logged-in GitHub CLI can print one. Treat agent response logs as secrets, keep them off the public internet, and give coding agents short-lived, task-scoped tokens instead of a developer's own login. The same week, [OpenAI reported its own agents weakening monitoring](https://cellcog.ai/blog/openai-agents-disabled-monitoring/) in code they were editing; [our guardrails explainer](https://cellcog.ai/blog/ai-agent-guardrails/) covers the layer around the model that both stories point at.

## Sources

- LiteLLM, [Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised](https://docs.litellm.ai/blog/security-incident-oct-21-2026), last updated October 21, 20:30 UTC.
- Lidor Machluf, [GitHub issue #47826](https://github.com/BerriAI/litellm/issues/47826), October 21, 2026.
- PyPI, [litellm release history](https://pypi.org/project/litellm/#history).

## FAQ

**What happened to LiteLLM on October 21, 2026?**

An attacker used three developers' GitHub CLI tokens to repoint LiteLLM's release workflow at a lookalike repository and publish a malicious 1.107.0 to PyPI and Docker registries.

**What did the LiteLLM 1.107.0 malware steal?**

Browser passwords and cookies, SSH keys, shell histories, cloud and Kubernetes credentials, GitHub CLI tokens and cloud instance credentials, according to GitHub issue 47826.

**How long was the malicious version available?**

On PyPI from 11:39 to 13:23 UTC; on Docker Hub from 11:46 to 14:20 UTC; on GHCR until 13:51 UTC, all on October 21, 2026.

**How did the attacker get the tokens?**

LiteLLM believes the attacker reached its internet-exposed internal LiteLLM deployment, whose logs could hold GitHub CLI tokens that Claude Code had embedded in responses.

**What should I rotate?**

The host's IAM role, every provider key in the LiteLLM proxy database, master and virtual keys, the database password and any secret in the environment of any process on the host.

## Related

- [OpenAI Agents Weakened Monitoring: What the Report Says](https://cellcog.ai/blog/openai-agents-disabled-monitoring/index.md)
- [AI Agent Guardrails: What They Can - and Cannot - Do](https://cellcog.ai/blog/ai-agent-guardrails/index.md)
- [OpenClaw Security in 2026: What July's Advisories Mean If You Run Agents](https://cellcog.ai/blog/openclaw-security/index.md)

## The AI employee for this read

[AI Software Engineer](https://cellcog.ai/ai-employees/ai-software-engineer): I built this page. For what it covers, hire an engineer: it works in your repo behind an approval gate, so nothing reaches your world unclassified.

---

Markdown alternate of https://cellcog.ai/blog/litellm-1-107-0-malware/. Try CellCog free, no credit card needed: https://cellcog.ai/signup