LiteLLM's Release Pipeline Was Hijacked for Two Hours and Shipped a Credential Stealer

Key points

• A malicious LiteLLM version 1.107.0 sat on PyPI and Docker Hub for roughly two hours on October 21, 2026 before being pulled.
• The attackers got in using GitHub CLI OAuth tokens stolen from three LiteLLM engineers, not by exploiting a software flaw.
• Developer BerriAI says Anthropic's Claude Code tool was, in specific situations, embedding users' GitHub CLI tokens into response bodies, which is the suspected leak path.
• Version 1.107.0 dropped three files, cook.pth, cook.py and sitecustomize.py, that ran automatically whenever Python started.
• The last clean version is v1.106.2, and all tokens tied to the incident have been revoked.

For about two hours on the morning of October 21, 2026, anyone who installed the popular AI gateway LiteLLM was pulling down a booby-trapped build. LiteLLM disclosed that threat actors compromised "multiple independent security controls" to push it.

LiteLLM is open-source software developers use to route requests to different AI models through one common interface. It's widely embedded in corporate AI stacks, which is what makes this one sting. We've followed LiteLLM's security record since our first report on 7 August 2026, when attackers slipped malicious code into an earlier release and left it live for three hours.

According to incident responders at Wiz, the malicious version 1.107.0 was uploaded to PyPI, the main repository for Python software, around 4:00 a.m. UTC. PyPI quarantined it roughly two hours later. Poisoned Docker container images carrying the same code were removed from GitHub Container Registry and Docker Hub shortly after that.

The last known safe release is v1.106.2.

How did the attackers get in?

They logged in as LiteLLM's own engineers. There was no exotic exploit here.

LiteLLM's maintainer, BerriAI, says the attackers used stolen GitHub CLI OAuth tokens belonging to three engineers on the project. GitHub CLI is the command-line tool developers use to work with GitHub from a terminal, and its OAuth token is effectively a password that proves you are that developer.

With those tokens in hand, the attackers used one engineer's account to kick off the project's release job and a second engineer's account to approve it. That meeting of two accounts was the exact control meant to stop a single rogue developer from shipping bad code. It didn't help when the attackers held both sets of keys.

Where did the tokens leak from?

BerriAI points, cautiously, at Anthropic's Claude Code. The company's follow-up note says that in specific situations, Claude Code, an AI coding assistant, was embedding a user's GitHub CLI OAuth token directly into a response body, where it could end up logged or stored by downstream tools, including LiteLLM's own gateway logs.

A tool meant to help engineers write code may have been quietly writing their credentials into places those credentials were never supposed to live.

What did the poisoned package actually do?

It ran code every time Python ran. When version 1.107.0 was installed, it dropped three files, cook.pth, cook.py and sitecustomize.py, straight into the Python site-packages folder. Python automatically executes files like these at interpreter startup, so the attacker's code ran without the victim doing anything beyond a normal pip install.

Wiz's writeup describes the payload as a credential stealer with backdoor behaviour. Anything the host machine had access to, cloud keys, API tokens, model provider credentials, was in reach.

What should affected users do?

If you or your team pulled LiteLLM during that window on October 21, treat the host as dirty. Downgrade to v1.106.2, delete cook.pth, cook.py and sitecustomize.py from site-packages, and rotate every secret the process could reach: cloud credentials, model provider API keys, any GitHub tokens stored on that machine.

If your developers use Claude Code with GitHub CLI logins, rotate those tokens too and audit any system that stores raw request or response bodies from AI assistants.

The uncomfortable judgement here: two-person release approval is only as strong as the laptops holding the approvers' tokens, and AI coding tools are now one of those laptops.