About 49,000 PyPI downloads hit a poisoned litellm build that stayed public for roughly two hours on 21 October 2026. The attackers never completed a fresh human login to publish. They reused GitHub CLI OAuth tokens that had already cleared two-factor authentication, after an unrevoked LiteLLM Agent Platform master key returned organization-owner power from a platform API call. According to LiteLLM’s canonical attack-chain analysis, that path shipped litellm==1.107.0 to PyPI and matching container images, then tried to erase release-run records. 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.
For the full attack-chain narrative, read the companion on legacymfa.sucks: LiteLLM PyPI attack via stolen GitHub tokens.
The first credential in the chain was not a workforce password prompt. 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 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 and was not scoped down. The API response returned that owner-level bearer token.
There was no interactive workforce sign-in in front of master-key use. No push. No one-time code. No hardware-bound ceremony. A long-lived shared secret in a public tree was enough to pull a high-privilege GitHub credential out of a 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.
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.
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.
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.” Branch protection changes, workflow edits, publish approvals, record deletion, and force-pushes all ran as ordinary bearer use of tokens GitHub already treated as 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, the publish path was reachable without a new authentication ceremony at the moment of release.
| Control surface | What the chain used | Why a login second factor never fired |
|---|---|---|
| Agent Platform master key | Public since May, presented in October | Shared API secret, no human login gate |
| Owner GitHub CLI OAuth token | Returned from platform config | Already post-2FA bearer material |
| Maintainer CLI tokens | Exfiltrated via throwaway CI | Replay of issued tokens, not a new sign-in |
| Branch protection and release gate | Overridden and dual-approved | Tokens already held the authority |
On 21 October 2026, roughly between 10:08 and 11:40 UTC, the owner token changed 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 went 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. 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, 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. Affected end-user or customer record counts have not been reported.
Why passkeys and phishing-proof MFA 2.0 do not block this replay
Device-bound, phishing-proof authentication hardens interactive human sign-in. It removes transferable passwords, OTP codes, SMS codes, email codes, and approval prompts from registration through decommissioning. That is the right control when an attacker is still trying to finish a workforce login.
The LiteLLM chain did not need that login. The Agent Platform master key was a non-human shared secret. MFA 2.0 does not enroll, bind, or challenge API master keys that were never user authenticators. Revoking a key left in a public repository is secret lifecycle work. It is not a second-factor problem.
The GitHub CLI OAuth tokens were issued after the engineers’ earlier authentications had already succeeded. Replaying those tokens did not open a new sign-in page. LiteLLM’s own analysis states the tokens are post-2FA and are not pulled into GitHub’s super-user 2FA reauth flows for sensitive organization or repository actions. Stronger login cryptography cannot re-challenge a bearer credential the platform already treats as finished authentication. Prevention, not detection still matters for the human login surface. It does not turn an already-stolen OAuth token into a dead string by itself.
Passkeys and FIDO2 put a key pair on the user’s device. The private key stays in hardware. The authenticator produces an origin-bound signature for a specific login ceremony. Industry language correctly calls that phishing-resistant at the login act: there is no reusable OTP or password for a proxy page to relay.
An enterprise identity provider that issues only hardware-bound signatures protects the human sign-in step. The ceremony proves possession of the enrolled device for that origin. It does not sit in front of an API master key. It does not invalidate a GitHub CLI OAuth token that was issued days earlier and is still accepted as a bearer header on org APIs. For LiteLLM’s publish path, the missing control was not a stronger human login gesture. It was the absence of a fresh, bound proof at the moment stolen tokens changed release machinery.
FIDO2 and passkeys are phishing-resistant at login only. Many deployments still allow phishable factors during enrollment, device onboarding, or recovery, which is why full-lifecycle phishing-proof coverage closes a different class of workforce attacks. LiteLLM’s October 2026 chain did not turn on helpdesk re-enrollment, a Temporary Access Pass readout, or a coached new-device ceremony. The engineers’ tokens were already issued. The Agent Platform held an owner-grade OAuth secret that automation could return to anyone with the master key. Tightening enrollment policy would not have revoked that master key or stripped owner scope from a platform-held CLI token. The lifecycle lesson here is secret and token governance after authentication, not a broken first-time authenticator registration.
Once phishing-proof device-bound sign-in is in place on workforce logins, remote phishing kits stop harvesting fresh interactive sessions. The residual path for live session or OAuth material becomes much harder: malware or mis-stored secrets on systems that already hold legitimate credentials. LiteLLM’s owner token was not harvested by coaching someone through a fake GitHub page. It was pulled from a platform configuration through an unrevoked master key, then used to steal more tokens from CI. That is secret storage, scoping, and token hygiene after authentication, not a missing push prompt at sign-in.
Controls that actually narrow a LiteLLM-style path
What would have narrowed this path in practice is boring and specific. Do not leave master keys in public trees. Revoke them the moment exposure is known. Never store an organization-owner GitHub CLI OAuth token on an automation platform as a non-service, non-scoped credential. Prefer short-lived, tightly scoped machine identities over human owner tokens embedded in config. Require step-up or token binding on branch-protection changes, workflow edits, and production publish approvals so a stolen bearer cannot silently dual-approve a release. Treat CI secrets as crown jewels with rotation and least privilege. Shortening token lifetime alone does not prevent first use of a stolen bearer. It only forces the attacker to re-steal sooner, and if the attacker can still approve publishes with a second stolen token, lifetime limits stop mattering.
Downstream, the roughly 49,000 PyPI downloads are a consumer supply-chain problem. Package quarantine, consumer detection, and endpoint secret hygiene contain installer malware. Login MFA on LiteLLM engineers does not scrub credentials stolen from someone else’s laptop after they pip-installed a poisoned wheel. The device-bound architecture is built for human authentication ceremonies, not for scrubbing malware that already ran on an installer endpoint.
| Failure | Login MFA / MFA 2.0 effect | Control that actually applies |
|---|---|---|
| Public Agent Platform master key | Does not bind or revoke API secrets | Secret scanning, immediate revoke, rotation |
| Owner CLI OAuth in platform config | Does not undo post-2FA bearer possession | No human owner tokens on platforms; scoped machines |
| Maintainer tokens via CI exfil | Does not stop workflow secret theft | CI secret isolation, least privilege, rotation |
| Dual-token publish and cover-up | Does not reauth every org action by default | Step-up on protection and release changes |
| Installer credential stealer | Outside workforce login | Package revoke, consumer controls, endpoint hygiene |
Key Takeaways for Defenders
- Revoke every master key the moment it appears in a public repository, and monitor API use for keys that should already be dead.
- Forbid organization-owner GitHub CLI OAuth tokens on automation platforms; use scoped machine identities instead of human owner bearers.
- Isolate CI secrets so throwaway workflows cannot exfiltrate GH_TOKEN-class material from private repos.
- Require step-up or bound approval on branch-protection changes, release-workflow edits, and production publish gates.
- Treat a successful malicious package publish as consumer malware response: quarantine, notify, and rotate secrets on installer endpoints, separate from login MFA upgrades.
Phishing-proof device-bound sign-in is the right answer when the attacker still needs a human login. When the attacker already holds post-2FA OAuth bearers and an unrevoked API master key, defenders win with revocation, scoping, and release-time proof, not with another prompt at yesterday’s sign-in.
FAQ
Would passkeys or phishing-resistant MFA have stopped the LiteLLM PyPI publish?
No. Passkeys and other phishing-resistant MFA harden the human login ceremony, but the LiteLLM publish reused GitHub CLI OAuth tokens that were already post-2FA and an Agent Platform master key that never faced a human login. According to LiteLLM’s attack-chain analysis, those CLI tokens are not subject to GitHub’s super-user 2FA reauth flows for sensitive organization or repository actions, so branch protection changes and release approval ran as bearer use without a new passkey assertion.
Why would MFA 2.0 not undo stolen LiteLLM GitHub CLI OAuth tokens?
MFA 2.0 would not undo the stolen LiteLLM GitHub CLI OAuth tokens because those tokens were already-issued bearer credentials after authentication, not transferable factors still waiting at a sign-in form. Phishing-proof device-bound MFA removes phishable factors from human identity lifecycle stages. It does not automatically revoke OAuth tokens stored on a platform or re-challenge every GitHub org action when the platform treats CLI tokens as finished authentication.
What control would have blocked the LiteLLM Agent Platform master key path?
Revoking the Agent Platform master key after its 27 May 2026 public commit, and never attaching an organization-owner GitHub CLI OAuth token to that platform as a non-service, non-scoped credential, would have blocked the documented first hop. LiteLLM’s canonical post shows the external IP used the still-valid master key on 10 October 2026 to obtain the owner token from platform configuration. That is API secret hygiene and credential scoping, not an interactive MFA gap.
Did enrollment failure drive the LiteLLM incident?
No. Public reporting on the LiteLLM October 2026 incident does not describe helpdesk recovery abuse, phishable enrollment codes, or attacker-driven new-device registration as the path to publish. The abused materials were an unrevoked master key and three engineers’ already-issued GitHub CLI OAuth tokens. Enrollment policy was not the failure mode LiteLLM documented for the malicious litellm==1.107.0 release.
What should defenders prioritize after a LiteLLM-style post-2FA token replay?
Defenders should prioritize immediate token and key revocation, removal of human owner OAuth secrets from automation, scoped machine credentials, CI secret isolation, and step-up on release and branch-protection changes. For the LiteLLM pattern, consumer package quarantine and endpoint secret rotation matter for anyone who installed the poisoned build. Upgrading only interactive login MFA leaves the bearer-replay and master-key paths untouched.
