On October 21, 2026, attackers hijacked LiteLLM’s release pipeline and published version 1.107.0 of the popular AI proxy library to PyPI and Docker registries, shipping a credential stealer and a remote backdoor to a package with about 23 million weekly downloads. It is the second supply chain compromise of LiteLLM in 2026, and LiteLLM’s own investigation turned up an unsettling detail: Claude Code can embed a user’s GitHub CLI OAuth token into a response body, and those tokens can end up in LiteLLM logs that were exposed to the public internet.

What Was Compromised?

Affected LiteLLM 1.107.0 artifacts

Graphic: GPTOnline, using LiteLLM assets

According to LiteLLM’s official incident report, the poisoned release was live on PyPI for approximately two hours, from 11:39 UTC to 13:23 UTC on October 21. All seven platform wheels (Linux, macOS, musl, Windows) carried the malware, and Docker Hub and GHCR tags including v1.107.0, latest, main-latest, and main-stable pointed to compromised images between 11:46 and 14:20 UTC. LiteLLM confirmed that enterprise customers running the private enterprise release were not impacted.

“In the early morning of October 21, LiteLLM’s release pipeline was compromised and pushed v1.107.0 to the docker registry and PyPi,” LiteLLM wrote. “This version contained compiled malware which steals credentials and loads remote-code execution tools.”

How the Attack Worked

Attack timeline, October 21, 2026 UTC

Graphic: GPTOnline, using LiteLLM assets

Security researchers at SafeDep, Socket, StepSecurity, and Upwind all flagged the malicious release, and The Hacker News and Datadog Security Labs published detailed analyses. The package dropped three files into the victim’s Python site-packages directory: cook.pth, cook.py, and sitecustomize.py. Because Python executes .pth files and sitecustomize.py every time the interpreter starts, the malware ran on every Python process on the machine, even if LiteLLM was never imported.

The first payload is a credential stealer calling itself privcollect, which harvests cloud tokens, SSH and GPG keys, browser data, and AI tooling credentials, then exfiltrates them to a lookalike domain, www.litellm.dev. “The first payload is a credential stealer that calls itself privcollect,” StepSecurity said. “The second payload forks a background daemon that checks a GitHub dead drop every hour and runs whatever Python the attacker serves.”

The attackers hijacked the release workflow itself. They used stolen GitHub CLI OAuth tokens from three engineers’ accounts to launch and approve an official release run, then pointed the trusted build pipeline at a lookalike repository, Berri-AI/litellm, which differs from the legitimate BerriAI/litellm by a single hyphen. “The attacker had to compromise multiple independent security controls to be successful,” LiteLLM wrote, noting the attacker even overrode branch protection with a token belonging to one of its two GitHub organization owners, and then deleted the workflow records to cover its tracks.

The Claude Code Connection

Perhaps the most consequential finding from the investigation concerns how the tokens leaked in the first place. LiteLLM identified an unexpectedly named user account in its internal LiteLLM deployment, which was exposed to the public internet. The attackers, it believes, got in through a recently patched vulnerability and pulled the tokens from the deployment’s logs.

“We have observed specific situations in which Claude Code will embed a user’s GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs,” LiteLLM wrote. The company says it is still working to confirm parts of this account of the incident and will publish updates as the investigation continues.

What Users Should Do

LiteLLM’s remediation guidance is blunt: if 1.107.0 was ever installed on a host with outbound internet, assume the exfiltration succeeded. Simply uninstalling the package is not enough, because the dropped payload files survive. Affected users must manually delete cook.pth, cook.py, and sitecustomize.py from every site-packages directory, kill the detached daemon, pin litellm==1.106.2 (or rebuild environments from scratch), and rotate all credentials the host could reach, including every provider key in the LiteLLM proxy database.

Why It Matters

LiteLLM is a widely used unified interface that lets developers call more than a hundred LLM providers through one API, and many companies run its proxy as the front door for their AI infrastructure. A compromise of its distribution channel therefore threatens not just one application, but the API keys and cloud credentials of everyone who updated in the wrong two hours. This is also the second LiteLLM supply chain incident this year; the earlier one, affecting versions 1.82.7 and 1.82.8, was linked by Datadog Security Research to TeamPCP activity in March. Datadog says no connection has been established between the two incidents.

The attack is another data point in a worrying pattern: AI developer tooling itself has become the target. With agents and coding assistants now holding OAuth tokens and API keys by default, a logging slip in one tool can become the foothold for compromising an entire software supply chain.

Sources