LiteLLM 1.107.0 Malware: What Happened and What to Do

§ 01Who is affected#

LiteLLM’s incident report draws the line by artifact and time. “Customers running the private enterprise release of LiteLLM were not impacted.”

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.

§ 02What the malware did#

The report that caught it, GitHub issue #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.

§ 03How 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.

§ 04Where 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.

§ 05What 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.

§ 06The 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 in code they were editing; our guardrails explainer covers the layer around the model that both stories point at.

§ 07Sources#

• LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised, last updated October 21, 20:30 UTC.
• Lidor Machluf, GitHub issue #47826, October 21, 2026.
• PyPI, litellm release history.