About 49,000 PyPI downloads landed on a poisoned litellm build that was live for roughly two hours. Attackers never needed a fresh human login. They reused GitHub CLI OAuth tokens that had already cleared two-factor authentication, after an unrevoked Agent Platform master key handed them organization-owner power. According to LiteLLM’s canonical attack-chain analysis of the 21 October 2026 incident, that path published litellm==1.107.0 to PyPI and matching container images, then tried to erase the release trail. Enterprise private-registry customers were unaffected. Public reporting has not named a threat actor, and it has not established how many end-user records, if any, were exposed downstream.
How a public master key opened the Agent Platform
On 27 May 2026, an Agent Platform master key was committed to the public LiteLLM-Labs/lite-harness repository. LiteLLM later identified that exposure. The key was not revoked.
On 10 October 2026, traffic from an external IP presented that still-valid master key to the Agent Platform API. The platform had been configured with a GitHub CLI OAuth token tied to an organization owner. The credential was not a service account. It was not scoped down. The API response handed the attacker that owner-level token.
There was no interactive workforce sign-in in front of master-key use. No push approval. No one-time code. No hardware-bound ceremony. A long-lived shared secret sitting in a public tree was enough to pull a high-privilege GitHub bearer credential out of a platform configuration that should never have held one in that form.
LiteLLM’s first public note had suspected tokens taken from logs of an internal deployment. The attack-chain post corrected that path. Request logs showed the first token came from the Agent Platform service reached with the unrevoked master key, not from the earlier internal-log theory.
How the attacker first learned the May key was still live is not detailed beyond observed API use from a given IP. That gap stays open in the public record.
Owner token, throwaway CI, two more maintainers
With the organization-owner GitHub CLI OAuth token, the attacker stood up throwaway continuous-integration workflows against private repositories. Between 10 and 12 October 2026 those jobs exfiltrated two additional maintainer GitHub CLI OAuth tokens, including CI secrets such as GH_TOKEN and RELEASE_PLEASE_TOKEN, plus other secrets from private repos.
Three engineers’ GitHub CLI OAuth tokens were abused in total. One carried organization-owner authority. The other two were maintainer-grade tokens recovered as workflow secrets.
According to Oliver Jensen and Mateo Wang in LiteLLM’s attack-chain post, “GitHub CLI tokens are post-2fa and not subject to GitHub's "super-user" 2fa reauth flows associated with sensitive organization or repository actions.” That single sentence explains the rest of the chain. Branch protection changes, workflow edits, publish approvals, record deletion, and force-pushes all ran as ordinary bearer use of tokens that GitHub already considered authenticated. Nothing in that path asked a human for a second factor again.
A temporary release policy made the final gate easier. Any two engineers could trigger and approve a release. A stricter physical-device special-account requirement had been relaxed. Combined with owner-level token power, that policy meant the publish path was reachable without a new authentication ceremony at the moment of release.
| Control | What happened here | Why it failed |
|---|---|---|
| Agent Platform master key | Public since May, used in October | Unrevoked shared secret, no login gate |
| GitHub CLI OAuth tokens | Owner plus two maintainer tokens replayed | Post-2FA bearer credentials, no step-up |
| Branch protection and release gate | Overridden and dual-approved with tokens | Tokens already held the authority |
| Consumer exposure | ~49k PyPI downloads in ~2 hours | Malware after a successful publish |
The two-hour litellm 1.107.0 window
On 21 October 2026, roughly between 10:08 and 11:40 UTC, the owner token bypassed branch protection and repointed the release workflow at a lookalike repository, Berri-AI/litellm. A second maintainer token approved the production gate. Seven wheels for litellm==1.107.0 were published to PyPI. Matching images went to Docker Hub and GHCR.
A third maintainer token deleted release-run records. Cover-up force-pushes followed.
Public report traffic began around 12:06 UTC. LiteLLM opened incident response. PyPI quarantined the package by about 13:23 UTC. Docker Hub and GHCR images were cleaned up. GitHub permissions tied to the abused tokens were removed.
While the build was live, PyPI recorded about 49,000 downloads of the malicious package. The payload stole browser credentials, cloud secrets, and AI API keys from environments that installed or ran it. LiteLLM has not published an exhaustive malware capability list beyond that credential and secret theft focus, and affected end-user or customer record counts have not been reported. Enterprise customers pulling from the private registry were stated as unaffected.
The damage after publish is a classic supply-chain problem for anyone who installed from the public index during that window. Revocation, consumer detection, and endpoint secret hygiene matter there. None of that is the same problem as stopping a phishable human login. The attackers already held issued OAuth tokens. Interactive two-factor authentication at GitHub sign-in had already succeeded in the past for the engineers who owned those tokens. Replaying the tokens did not require another sign-in.
Process-improvement detail beyond the attack chain is deferred in LiteLLM’s own writing to a later post. What the 23 October analysis does establish is the sequence: unrevoked master key, owner token from the Agent Platform, maintainer tokens via CI exfiltration, lookalike release source, dual-token publish, short public window, cleanup.
Login hardening, including phishing-resistant device-bound sign-in for humans, does not revoke a master key left in a public repository. It does not shrink an org-owner GitHub CLI OAuth token that was stored on a platform as a non-service, non-scoped credential. It does not re-challenge every sensitive org action when GitHub treats CLI OAuth tokens as post-2FA bearer material. Those are secret-lifecycle, token-binding, scoping, and release-gate failures sitting after authentication has already happened.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: why post-2FA GitHub tokens outran login MFA in LiteLLM.
FAQ
How did attackers first get into LiteLLM’s release path?
Attackers first reached LiteLLM’s release path by presenting an unrevoked Agent Platform master key that had been committed to a public repository on 27 May 2026 and was still valid in October. According to LiteLLM’s attack-chain post, that key called the Agent Platform API from an external IP on 10 October 2026 and returned an organization-owner GitHub CLI OAuth token that had been configured on the platform as a non-service-account, non-scoped-down credential.
Why didn’t GitHub 2FA stop the malicious litellm publish?
GitHub 2FA did not stop the malicious litellm publish because the attackers reused GitHub CLI OAuth tokens that were already post-2FA. LiteLLM’s analysis states those CLI tokens are not subject to GitHub’s super-user 2FA reauth flows for sensitive organization or repository actions, so branch protection changes, workflow repointing, publish approval, and cover-up force-pushes ran without a new human second factor.
What did the malicious litellm 1.107.0 package do?
The malicious litellm 1.107.0 package stole browser credentials, cloud secrets, and AI API keys from environments that installed or ran it. It was published to PyPI as seven wheels and also shipped as Docker Hub and GHCR images, stayed public about two hours on 21 October 2026, and drew roughly 49,000 PyPI downloads before quarantine. LiteLLM stated enterprise private-registry customers were unaffected.
Were customer databases or end-user records confirmed stolen from LiteLLM itself?
No public figure confirms customer database or end-user record counts stolen from LiteLLM systems in this incident. The documented impact centers on abuse of three engineers’ GitHub CLI OAuth tokens, a poisoned public package and container images, and credential-stealing malware on installer endpoints. Affected end-user record counts remain unreported.
Is a named threat group tied to the LiteLLM October 2026 attack?
No named threat actor or group is publicly attributed in LiteLLM’s canonical attack-chain write-up. The post focuses on the technical sequence from the unrevoked master key through token theft and the short malicious release window, without assigning a group name.
