LiteLLM 1.107.0 carried a credential stealer. How to check, and which logins to replace

What happened on October 21

On October 21, 2026, a poisoned build of LiteLLM, the Python library and proxy that puts more than 100 model providers behind one OpenAI-compatible API, went out through its developers’ own release pipeline. Datadog puts LiteLLM at about 23 million downloads a week. It’s the second time this year: in March, versions 1.82.7 and 1.82.8 were poisoned too.

LiteLLM’s incident post lists what was affected:

• PyPI: litellm==1.107.0, all seven wheels, from 11:39 to 13:23 UTC (4:39 to 6:23 a.m. Pacific).
• Docker Hub: the v1.107.0, latest, main-latest and main-stable tags, from 11:46 to 14:20 UTC.
• GHCR: the same tags of litellm, litellm-database and litellm-non_root, from 11:46 until 13:51 UTC.

The v1.107.0 tag on GitHub is clean: the packages were built from a lookalike repository, Berri-AI/litellm. A community member, Lidor Machluf, flagged the release in issue #47826 at 12:06 UTC.

The way in was a key nobody revoked. According to LiteLLM’s October 23 record, an opencode.json file committed to a public LiteLLM repository on May 27 held the master key to an internal agent platform. On October 10, the attacker used it to pull a GitHub organization owner’s GitHub CLI token from the platform, then two more maintainers’ tokens through throwaway CI runs. On October 21, those tokens repointed the release workflow, approved the release and deleted the run records.

What the malware does

Each wheel drops cook.pth, cook.py and sitecustomize.py into site-packages. Python runs them whenever it starts in that environment, pip included, whether or not anything imports LiteLLM.

• A stealer. StepSecurity’s analysis lists what it takes: browser passwords and cookies, SSH and GPG keys, cloud and Kubernetes credentials, GitHub, npm and PyPI tokens, .env files, shell history, the provider keys in a LiteLLM proxy’s database, and the credentials of more than 20 AI coding tools, Claude Code, Codex, Gemini CLI, Cursor, GitHub Copilot, OpenCode and Aider among them. It encrypts the lot and sends it to a lookalike domain.
• A backdoor. On Linux and macOS, a background process reads a file on GitHub every hour and runs whatever code the server named there returns. StepSecurity says that stage was never armed, and Datadog that no second-stage payload was seen in the wild, but the GitHub account is gone, and whoever registers its name again could run code on machines still infected. On Windows the backdoor fails; the stealer still runs.

Who it affects

How you got LiteLLM	Affected?
An install or upgrade that took 1.107.0, between 11:39 and 13:23 UTC	Yes
The v1.107.0, latest, main-latest or main-stable image, started between 11:46 and 14:20 UTC	Yes
Any other version, pinned in a requirements file or lockfile	No
The v1.107.0 source tag from GitHub	No
LiteLLM’s private registry for Enterprise customers	No, says LiteLLM

You can have it without choosing it. Many projects accept any newer LiteLLM, StepSecurity notes, “so a fresh install or lockfile refresh would have picked up 1.107.0 as soon as it was published,” and proxies tracking latest or main-stable “picked it up on their next pull or restart.” Here is what some agent tools accept, in the release each had out on October 21, according to PyPI:

Tool	LiteLLM it accepts	Could it have taken 1.107.0?
Aider (aider-chat 0.86.2)	1.81.10 only	No
OpenHands (openhands-ai 1.11.0)	1.84.1 only	No
OpenHands CLI (openhands 1.16.0)	1.83.7 or later, through openhands-sdk 1.21.0	Yes
DSPy (dspy 3.4.1)	1.65.8 or later	Yes
mini-swe-agent (2.4.6)	1.75.5 or later, except 1.82.7 and 1.82.8	Yes
Open Interpreter (open-interpreter 0.4.3)	1.41.26 or later, below 2.0	Yes

“Yes” means a new install or upgrade in the window, without a lockfile, could have taken it. And wherever it ran, it went after the logins of every agent on that machine, not just the Python ones.

If your team routes Claude Code or another agent through a LiteLLM proxy that ran one of those images, the provider keys behind it were within the stealer’s reach, in the proxy’s database or its environment. LiteLLM says to replace them, the master key and the virtual keys, so each developer will need a new gateway key too.

How to check

LiteLLM’s post suggests pip show litellm, but it also warns that pip starts Python, which runs the malware again. Look for the files from the shell first. StepSecurity’s checks, for a Mac or Linux machine, Docker images and lockfiles:

find / -name cook.pth -path "*site-packages*" 2>/dev/null
ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null
lsof /tmp/remote_code_loader.lock 2>/dev/null
docker images --digests | grep -E 'berriai/litellm|litellm/litellm'
grep -rniE "litellm[=<>~! ]*1\.107\.0([^0-9rc]|$)" . --include=requirements*.txt --include=*.lock --include=pyproject.toml --include=Pipfile*

A cook.pth, either /tmp file, or an image index LiteLLM lists, such as sha256:1bbcb1443bc9…, means the machine ran it. Finding nothing doesn’t prove a machine is clean, LiteLLM warns.

If it ran

LiteLLM’s steps, with StepSecurity’s additions:

1. Don’t start Python first. From the shell, delete cook.pth, cook.py, sitecustomize.py and their .pyc copies in __pycache__ from every affected site-packages.
2. Stop the background process that holds /tmp/remote_code_loader.lock.
3. Rebuild the environment or image from scratch, pinned to a clean version, and purge 1.107.0 from any package cache or mirror.
4. Assume the theft worked if the machine could reach the internet.
5. Replace every secret it could reach: cloud roles and keys, SSH keys, registry and CI tokens, saved browser passwords, a proxy’s keys and database password, and every AI tool’s login. On AWS, check CloudTrail for GetCallerIdentity calls from the instance role around the install.

Replacing agent logins and keys

Claude Code keeps its login in ~/.claude/.credentials.json on Linux and Windows, and in the Keychain on a Mac. Codex keeps its in ~/.codex/auth.json or the system’s credential store, and says to “treat ~/.codex/auth.json like a password.” The analyses don’t say whether the stealer reaches the Keychain, so treat a Mac’s logins as taken too.

Signing out deletes your copy, which may not stop the stolen one: GitHub’s CLI manual says gh auth logout “does not revoke authentication tokens.” Cancel each login where it was issued:

Login	Where to cancel it
Claude Code on a Claude plan	On claude.ai, Settings > Account lists Claude Code sign-ins with your other sessions, and you can log them out there; if they aren’t listed, remove the token under Settings > Claude Code, says Anthropic
Codex on a ChatGPT plan	ChatGPT’s Settings > Security > Active sessions has Log out all, but OpenAI says the list doesn’t show or manage Codex CLI sessions. It also says to change your password if you use one, and to contact support
GitHub CLI	At github.com/settings/applications, choose GitHub CLI, then Revoke Access. It revokes every token the CLI has made, on all your devices, says GitHub
A provider API key	Delete it in the provider’s console and create a new one, as Anthropic’s guide describes for Claude keys
A LiteLLM proxy	Every provider key in its database, then its master and virtual keys, says LiteLLM

Then sign each agent in again. If you run them in Enjoy, each agent uses its own login, the one your terminal uses, plus any extra accounts you’ve saved for Claude Code, Codex or Grok Build. Each is a separate login to cancel. Once you have, sign each agent back in from its agent settings.

What LiteLLM hasn’t said

• How many machines installed 1.107.0. It hasn’t published a download count.
• What it’s changing. “We’ll share that next week,” it wrote on October 23. On October 24 it published its first releases since, 1.106.3 the newest, signed with a new key.
• When a separate fix goes public. Its Enterprise release fixes “a vulnerability whose disclosure date is scheduled for October 27.” LiteLLM hasn’t said when the public releases get it.
• Who did it. LiteLLM hasn’t named the attacker, whose searches of its other systems had “a primary focus on upstream inference API tokens.” Railway called its own October 21 breach part of “a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.” No one has tied the two together, or to the OpenCode Console breach of October 17.

We’ll update this memo when LiteLLM publishes its changes or the October 27 disclosure.