LiteLLM's Second Breach Began With a Key Nobody Revoked

The malicious LiteLLM 1.107.0 release that hit PyPI on October 21, 2026 did not start with a clever exploit. It started with an administrative key that was committed to a public GitHub repository on May 27, deleted from the file, and never revoked. Four and a half months later, someone used it.

That key opened an internal LiteLLM Agent Platform deployment. The platform held the GitHub CLI OAuth token of the company's GitHub organization owner. From there the attacker took over the release pipeline and shipped a credential stealer that ran on every Python start. LiteLLM's own root cause write-up calls it "a strong illustration of the risks associated with failing to rotate a potentially exposed key."

This is the second time this year LiteLLM's PyPI package has been poisoned. In March, a different chain through the Trivy scanner produced versions 1.82.7 and 1.82.8, which I covered in the Mercor breach analysis. None of the sources I read link the two incidents. The lesson they share is the same, though: an AI gateway is a vault of other people's keys, and attackers have noticed.

If you installed or ran LiteLLM 1.107.0, treat the host as compromised and rotate everything it could reach. The rest of this post explains why, and what I would change this week even if you never touched that version.

What happened, in order

All times are UTC and come from LiteLLM's October 23 root cause analysis, written by Oliver Jensen and Mateo Wang, unless another source is named.

When	What
May 27	A config file containing an administrative key to an internal LiteLLM Agent Platform deployment is committed to the public LiteLLM-Labs/lite-harness repo. A follow-up commit deletes the file. The original commit stays in public history until October 22. "Because of human error, nobody followed through on revoking the administrative key."
Oct 10, 21:13 to 21:28	The attacker makes authenticated API calls to the Agent Platform. One call returns the GitHub CLI token of the GitHub organization owner.
Oct 10, 22:11 to 22:14	Workflows on throwaway branches in two repositories post CI secrets, including two maintainers' tokens, to webhook.site. The runs are deleted within about three minutes. Socket notes October 10 is the earliest date it can evidence.
Oct 12	A second round of secret collection runs across private repositories.
Oct 21, 10:08	A push is rejected by branch protection, then succeeds using the owner's token.
Oct 21, 11:11	The production release gate is approved with a maintainer's stolen token.
Oct 21, 11:39	Seven litellm==1.107.0 wheels are published to PyPI. Docker Hub and GHCR images follow at 11:46.
Oct 21, 12:06	Researcher Lidor Machluf opens GitHub issue #47826 identifying the compromise.
Oct 21, 13:23	PyPI quarantines the release. Docker tags are removed or repointed by 14:20.
Oct 23	LiteLLM publishes the root cause analysis, plus analyses from Microsoft and others.

Two details in that timeline matter more than the rest. First, LiteLLM says GitHub CLI tokens "are not scoped, are post-2fa," and are not subject to GitHub's reauthentication prompts for sensitive actions. One stolen token gave the attacker owner capabilities over the whole organization. Second, a LiteLLM release normally needed sign-off from a special account locked to a physical device in the company's office. That restriction had been relaxed earlier the same week to let any two engineers trigger and approve a release, to support more frequent releases and backports.

What the malicious package did

Microsoft's analysis found the wheel installed Python startup files, cook.pth and sitecustomize.py, outside the LiteLLM folder. Python runs them at interpreter start, so the stealer fired even if nothing imported LiteLLM. It collected cloud credentials, Kubernetes service account files, SSH and GPG keys, browser credential data, environment variables, and the authentication files of AI coding tools and MCP integrations. It also queried the LiteLLM proxy database, which is where gateway operators keep their upstream provider keys.

Wiz, citing ClickPy data, puts downloads of 1.107.0 at about 49,000 during the window. Wiz also reported seeing instance role credentials harvested from CI runners and Kubernetes nodes in multiple environments, with the attacker validating them about 4.5 hours after exfiltration. That is the number I would put in front of any team that plans to rotate keys "next sprint."

Known and unknown

Known	Not yet known
Entry point: an unrevoked admin key exposed since May 27	Who the attacker is. None of the sources I read attribute it.
Affected artifacts: 1.107.0 on PyPI, plus the v1.107.0, latest, main-latest and main-stable images	How many of the roughly 49,000 downloads actually executed on a host with secrets
Safe pin: 1.106.2 or any explicit earlier version, per LiteLLM	Whether a second-stage payload ran anywhere. Microsoft did not confirm one.
Enterprise customers on LiteLLM's private registry were not impacted, per LiteLLM	How the attacker found the key, and whether activity began before October 10

The identity lesson: three non-human identity failures in one chain

Nothing in this chain needed a zero-day. Every step was a credential doing exactly what it was allowed to do. I have spent more than 15 years in identity, and this is the pattern I see most often: the breach is an authorization story told in the language of supply chain.

Deleting a secret is not revoking it. The team removed the file and moved on. Git history, forks, clones and secret scanners all keep what you delete. The only remediation for an exposed key is to make it stop working, then confirm it stopped working. A leaked key with no revocation record should be treated as live, because in this case it was, for 136 days.

The agent platform carried a human's master credential. An internal platform built to run AI agents stored the organization owner's GitHub CLI token, which has no scopes. That is an agent borrowing the most powerful human identity in the company. My read: this is the default pattern across the industry right now, because a personal token is the fastest way to make an agent useful. The identity primitives on the Agent Security Map exist precisely because agents need their own scoped, revocable identities instead of a human's leftovers.

The human checkpoint was traded for speed. A device-bound release approver is a strong control. Relaxing it to any two engineers turned two stolen tokens into a valid approval. I do not read this as carelessness. It is what release pressure does to every team, and it is why the strong path has to also be the easy path.

There is a fourth point specific to AI. A gateway like LiteLLM exists to hold keys for many model providers in one place. The stealer went straight for the proxy database. Anything that concentrates credentials for agents, from gateways to MCP servers, is now a priority target in its own right.

What security and product teams should do this week

1. Check for 1.107.0 from a clean system. LiteLLM's incident post lists what to look for: the litellm-1.107.0.dist-info folder, cook.pth, sitecustomize.py, and the affected image digest. Microsoft warns not to run python or pip inside a suspect environment, because that reruns the hooks.
2. Rebuild, do not uninstall. Microsoft is explicit: "Removing the package or a release tag is not sufficient recovery." Rebuild virtual environments and images from pinned, verified artifacts.
3. Rotate everything the host could reach, then revoke sessions. LiteLLM lists the instance or task IAM role, every provider key in the proxy database, master and virtual keys, the DATABASE_URL password, and process environment secrets. Microsoft adds that rotating a key may not kill active tokens, so revoke sessions too.
4. Hunt in your cloud logs. LiteLLM suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time, and for use of those credentials from outside your infrastructure.
5. Pin by hash and by digest. Unpinned installs pulled 1.107.0 automatically. Hash-pinned lock files and image digests would have stopped it.
6. Audit your secret-leak backlog for revocation, not removal. Pull every secret-scanning alert from the last year and ask one question per alert: is there proof the credential was revoked?
7. Inventory tokens held by agent platforms. List every token your agent tooling stores, whose identity it represents, and its scopes. Replace personal and unscoped tokens with GitHub Apps or fine-grained tokens bound to a single repository and short expiry.
8. Put the release gate back on hardware. If your release approval can be satisfied by tokens alone, a token thief can satisfy it. Require a device-bound approval for publishing to public registries.

If you need a starting structure for items 6 and 7, my guide to credential lifecycle management for AI agents covers short-lived tokens, and the agent supply chain category on the Agent Security Map lists vendors working on this layer.

What I expect next

My read, clearly labelled as opinion:

• More attacks on AI gateways and agent platforms. Two poisoned LiteLLM releases in seven months show attackers value tools that sit between applications and model providers. I expect the same attention on MCP servers and agent orchestrators that store tokens.
• Pressure on unscoped developer tokens. The "post-2fa, not scoped" property LiteLLM described is the root of the blast radius. I expect security teams to start blocking personal CLI tokens in automation, and I expect platforms to face questions about them.
• Revocation evidence becomes an audit question. Today most programs track whether a leaked secret was found. The next question from auditors and buyers will be when it stopped working, and who verified it.
• Downstream disclosures. Wiz has already seen stolen cloud credentials validated. Some organizations that ran 1.107.0 will find follow-on access over the coming weeks, the way Mercor did after the March compromise.

FAQ

Which LiteLLM version was compromised in October 2026?

LiteLLM 1.107.0, published to PyPI on October 21, 2026, along with the v1.107.0, latest, main-latest and main-stable Docker images. LiteLLM says to pin 1.106.2 or any explicit version published before the incident.

How did attackers get into LiteLLM's release pipeline?

An administrative key to an internal LiteLLM Agent Platform deployment was committed to a public repository on May 27 and never revoked. On October 10 the attacker used it to retrieve the GitHub organization owner's GitHub CLI token. That token, plus two stolen maintainer tokens, let them push code and approve a release.

Is uninstalling LiteLLM 1.107.0 enough?

No. The package installed Python startup files outside the LiteLLM folder that run whenever Python starts. Microsoft says removing the package or release tag is not sufficient. Rebuild the environment from verified artifacts and rotate every credential the host could reach.

What did the LiteLLM malware steal?

According to Microsoft and Wiz, it targeted cloud credentials for AWS, Azure and Google Cloud, Kubernetes files, SSH and GPG keys, and browser credential data. It also took environment variables, AI coding tool and MCP configuration, LLM provider API keys, and records from the LiteLLM proxy database.

Is this the same as the March 2026 LiteLLM attack?

No source I read links them. March involved versions 1.82.7 and 1.82.8, published after attackers took publishing credentials through a compromised Trivy scanner. October started with an unrevoked agent platform key. Both show that an AI gateway holding many provider keys is a high-value target.

Sources

• LiteLLM: Root cause analysis of the October 21, 2026 attack chain (Oct 23, 2026)
• LiteLLM: Contained, release v1.107.0 compromised (Oct 21, 2026, updated Oct 23)
• Microsoft Security: Inside the LiteLLM 1.107.0 supply chain compromise (Oct 23, 2026)
• Wiz: LiteLLM compromised, steals credentials (Oct 21, 2026)
• Socket: Secret-stealing workflows ran 11 days before the attack (Oct 23, 2026)
• GitHub: BerriAI/litellm issue #47826 (Oct 21, 2026)