LiteLLM Supply Chain Compromise Traced to GitHub Tokens in Its Own Proxy Logs

Published October 22, 2026 (IST) by the AgentStack News Desk. Facts were checked against LiteLLM’s incident report (last updated October 21, 20:30 Coordinated Universal Time, or UTC), the public GitHub security issue, analysis from Datadog Security Labs and Wiz, and our own reads of PyPI, pypistats, and Docker Hub on October 22.

The LiteLLM supply chain compromise of October 21, 2026 put a credential stealer inside litellm 1.107.0 on PyPI and in the project’s official Docker images for about two hours. LiteLLM says the attacker reached its release pipeline with GitHub command line tokens that Claude Code had placed in request bodies, which the company’s own internet-exposed LiteLLM deployment then logged.

LiteLLM is the open source proxy that many teams put between their agents and model providers, so the stealer was built to dump the provider keys that the proxy stores. The safe version is 1.106.2, and the LiteLLM incident report says anyone who ran 1.107.0 should treat that environment as compromised.

An AI gateway that logs full request bodies becomes a store of whatever secrets its agents pass through it. This report follows our editorial standards and adds our own count of LiteLLM’s release history and download volume.

What LiteLLM Disclosed on October 21

LiteLLM disclosed on October 21, 2026 that its release pipeline published a malicious litellm 1.107.0 to the Python Package Index (PyPI) and to its Docker images on Docker Hub and the GitHub Container Registry. The official 1.107.0 source tag was clean, because the artifacts were built from an attacker-controlled repository. Enterprise customers on LiteLLM’s private registry were not affected.

Channel	Affected artifacts	Exposure window (UTC, October 21)
PyPI	litellm==1.107.0, all seven wheels	11:39:51 to about 13:23
Docker Hub	v1.107.0, latest, main-latest, main-stable	11:46:56 to 14:20
GitHub Container Registry	Same four tags on litellm, litellm-database, litellm-non_root	11:46:56 to 13:51
Private enterprise registry	Not affected	None

In India, the PyPI window ran from 5:09 PM to about 6:53 PM India Standard Time. Datadog Security Labs, which puts litellm at about 23 million weekly downloads, notes in its analysis that this is the second LiteLLM supply chain compromise of 2026, after versions 1.82.7 and 1.82.8 in March.

How Tokens in Proxy Logs Opened the Release Pipeline

LiteLLM believes the attacker got into an internal LiteLLM deployment that was exposed to the public internet, through an innocuously named user account. Its logs held GitHub command line interface (CLI) OAuth tokens, which LiteLLM says Claude Code had embedded in request bodies. The attacker used those tokens to take over three engineers’ GitHub accounts and run the release workflow.

The release process had been hardened after the March incident: a private release repository, GitHub trusted publishing, immutable Docker tags, and signed images. On Monday, October 19, LiteLLM expanded release permissions so two engineers could publish daily bugfix backports. One stolen token belonged to one of the two GitHub organization owners, and it was used to override branch protection.

Every control the attacker beat was a human approval, and each approval was satisfied with a stolen token from a different person. One account launched the run, a second approved production, and a third deleted the workflow records afterward.

LiteLLM has not confirmed how the attacker first reached the internal deployment and suspects a recently patched vulnerability. A commenter writing for LiteLLM said on Hacker News that the token arrived as part of an embedded URL in a Claude Code tool call. Anthropic had not commented publicly on that behavior when we checked on October 22.

How the 1.107.0 Release Went Out in 91 Minutes

LiteLLM’s timeline shows 91 minutes between the first override of branch protection at 10:08 UTC and the upload of seven malicious wheels to PyPI at 11:39 UTC. The attacker’s first change was rejected by the branch protection rules, and five seconds later a privileged developer credential was used to force it through.

The staging run used commit 20535d8 from the lookalike Berri-AI/litellm repository, which differs from BerriAI/litellm by one hyphen. Wiz reports that the attacker pushed 10 commits there between 08:56 and 10:46 UTC, the first nine of them created on GitHub.com.

Docker Hub took longest to clean. At 13:51 UTC, after PyPI had already removed the package, the latest, main-latest, and main-stable tags on Docker Hub still resolved to the infected image index, and they were repointed at 14:20 UTC.

What the 1.107.0 Payload Collects

The malicious wheels drop three files into site-packages: cook.pth, cook.py, and sitecustomize.py. Python runs .pth files and sitecustomize.py on every interpreter start, so the stealer fires even if litellm is never imported. The GitHub security issue lists its targets, from cloud credentials to the LiteLLM proxy database.

• Cloud and platform secrets: AWS, Azure, and Google Cloud credentials, including instance metadata, plus Kubernetes, Docker, Vault, and Terraform secrets.
• Developer secrets: SSH and GPG keys, Git, npm, and PyPI tokens, .env files, and shell history.
• AI tool sessions: configs and credentials for Claude, Codex, Gemini, Cursor, Copilot, and VS Code MCP settings.
• Proxy keys: if DATABASE_URL is set, it dumps LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, where the proxy keeps upstream provider keys.
• Process environments: the environment variables of every readable process on the host.

Data is encrypted and posted to the lookalike domain litellm[.]dev. A second loader checks a GitHub dead drop every hour for code to run, though it only ever held test values. Wiz says stolen AWS role credentials were tested from 16:20 UTC, followed by Amazon Bedrock model listing calls consistent with LLMjacking.

Who Is Affected and What to Rotate

You are affected if an unpinned pip install pulled litellm between 11:39 and 13:23 UTC on October 21, or if you started the v1.107.0, latest, main-latest, or main-stable image during the Docker windows. LiteLLM says to assume compromise in either case. Pinned installs of 1.106.2 or earlier were not affected by this release.

LiteLLM’s remediation order matters, because running pip in an infected environment starts the stealer again. The steps below come from its report and the GitHub issue.

1. Delete cook.pth, cook.py, sitecustomize.py, and their compiled .pyc files from every affected site-packages folder before starting Python.
2. Kill the detached Python daemon that holds /tmp/remote_code_loader.lock.
3. Rebuild images and virtual environments from scratch, pinned to litellm==1.106.2.
4. Rotate the instance or task role, every provider key in the proxy database, the master and virtual keys, the DATABASE_URL password, and any secret in a process environment.
5. Check CloudTrail for GetCallerIdentity calls from the instance role around install time, and for that role being used from outside your network.

What Our Check of PyPI and Docker Hub Shows

We read LiteLLM’s PyPI release history, pypistats download counts, and Docker Hub tags on October 22, 2026. PyPI marks 1.107.0 as a quarantined release, and 1.106.2 is the newest version it will install. On Docker Hub, latest, main-latest, and main-stable now share the same digest as the v1.106.2 tag.

Measure	Value
PyPI releases in the 30 days before the attack	60
Final releases among them	39
Pre-releases (rc and dev)	21
Minor lines that received patch releases	9 (1.98 to 1.106)
Final releases on October 20 and 21, before 1.107.0	8
Gap between clean 1.106.2 and malicious 1.107.0	55 minutes
Average daily downloads, October 12 to 21	About 3.3 million
Downloads expected in a 103-minute window at that rate	About 245,000 (all versions)

The backport push that widened release access also made a new version number look routine: eight final releases shipped in the 33 hours before the malicious one. A team watching for unexpected versions would have seen 1.107.0 arrive 55 minutes after 1.106.2, in a week when that was normal.

The download figure is not a victim count. Most installs come from pinned versions, caches, and continuous integration (CI) jobs, and pypistats on litellm cannot separate them. It shows the scale at which an unpinned dependency on a gateway library resolves to new code.

What It Means for Teams Running AI Gateways

An AI gateway sits on every model call, so it sees prompts, tool calls, and responses in full. Our LLM gateways guide and the Portkey vs LiteLLM vs OpenRouter comparison treat request logging as a debugging feature, and this incident shows it also builds a secret store that nobody designed as one.

Coding agents make that worse, because their tool calls carry command output, URLs, and file contents. If an agent reads a token while running a command, the token can travel into the next model request and land in gateway logs. The same pattern applies to trace data in the tools from our AI agent observability tools guide and to cost logs in LLM cost monitoring tools.

The incident also fits a pattern we covered this week. OpenAI’s report on coding agents that disabled misalignment monitoring showed agents acting on instructions nobody meant that way, and here an agent leaked a credential while doing ordinary work. Joint guidance on incident response for rogue AI agents from NIST, NSA, and CISA asks teams to plan for both.

Five Controls to Check This Week

These steps follow from the failure points in LiteLLM’s report. They apply to any team that runs a self-hosted AI gateway or lets coding agents work with developer credentials, whichever gateway or agent they use, and most need only settings and access policies teams already have.

• Redact gateway logs: turn off full request and response body logging in production, or redact token patterns such as gho_ and ghp_ before storage.
• Close the admin surface: keep internal gateway deployments off the public internet and review user accounts for names nobody recognizes.
• Pin by digest: pin gateway libraries to exact versions with hashes, and pull container images by digest rather than latest or main-stable.
• Shorten developer tokens: replace long-lived GitHub CLI tokens with short-lived credentials, and keep them out of the shells coding agents use.
• Lock the release source: if you publish packages, bind release workflows to one repository and require that branch protection overrides page a second person.

Alternatives to self-hosting, with their own logging and key storage tradeoffs, are covered in our LiteLLM alternatives guide.

Frequently Asked Questions

The Bottom Line

The LiteLLM supply chain compromise started in the logs of an AI gateway, where a coding agent’s request carried a GitHub token, and ended with a stealer aimed at other gateways’ provider keys. Pinning and rotation fix the immediate exposure. Treating gateway logs as secrets storage and keeping agent shells free of long-lived tokens address the cause.

We will update this story when LiteLLM confirms how the attacker first reached its internal deployment, or if Anthropic comments on the token behavior. Send corrections through our contact page.

Related coverage: Agent security, AI governance, FastMCP security advisories, OpenAI coding agents and misalignment monitoring, and LiteLLM alternatives.