Skip to content
NewsIncident

A leaked LiteLLM master key sat unrevoked for five months, then became a supply-chain attack

· by Pondero Newsdesk

The short version

LiteLLM said an Agent Platform master key exposed on GitHub in May 2026 went unrevoked and let an attacker steal an unscoped owner-level GitHub token, rewrite its release pipeline, and ship a backdoored package to PyPI.

A leaked LiteLLM master key sat unrevoked for five months, then became a supply-chain attack

A master key for LiteLLM's Agent Platform leaked onto a public GitHub repository in May 2026, and LiteLLM's own revocation process missed it, according to the company's incident writeup. Five months later, on October 10, an attacker used that same unrevoked key to reach the platform, steal a GitHub token with owner-level access, and eventually rewrite LiteLLM's release pipeline to ship a malicious package.

What happened

LiteLLM engineers Oliver Jensen and Mateo Wang said a configuration file committed to the public LiteLLM-Labs/lite-harness repository on May 27, 2026 contained the master key to an Agent Platform deployment the company uses to orchestrate agents, per the writeup. The team caught the leak, force-pushed over the commit, and flagged the key for revocation, but the master key itself never got revoked. On October 10, an unknown attacker used it to log into the Agent Platform and extract a GitHub CLI OAuth token tied to the organization's owner account. The token was not scoped to any specific repository or permission, so it worked across every repo in LiteLLM's GitHub organization.

From there the attacker moved in two bursts, per Socket's independent timeline. On October 10 and again on October 12, they pushed a workflow file to short-lived branches that ran, harvested secrets, and deleted themselves within minutes, each time grabbing more: GitHub tokens, a GitHub App signing key, and credentials for Linear, Together AI, Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian's own secret-scanning service. On October 21, the attacker used stolen maintainer tokens to override branch protection, repoint the release pipeline at a lookalike repository named "Berri-AI/litellm" instead of the real "BerriAI/litellm," and push a malicious build of LiteLLM, all before Upwind researcher Lidor Machluf reported the attack around noon UTC that day. PyPI quarantined the resulting package, version 1.107.0, about 90 minutes later.

An unscoped owner token is why one old key became a full breach

The attack chain only worked because two separate safeguards had already loosened. LiteLLM had relaxed its release-approval rule earlier in October to speed up bugfix backports, dropping a requirement that releases be approved from a device physically locked in its office down to approval by any two engineers, a gap the attacker exploited using two stolen tokens rather than one. And the GitHub token the attacker stole in the first place carried organization-owner privileges with no scope restriction at all, so a single credential theft gave them write access everywhere rather than to one repository. For any team running CI tokens or platform master keys, the lesson is specific: a leaked key that "gets flagged for revocation" is not the same as a revoked key, and an owner-level token with no scope limit turns a single leak into an organization-wide compromise.

The package itself carried real teeth. According to Microsoft's security research team, the malicious build installed startup hooks that ran automatically whenever Python launched in an affected environment, even if the application never imported LiteLLM, and the hooks lived outside the LiteLLM application directory, so deleting the package alone could leave the backdoor running.

What to watch next

LiteLLM said it is revoking every token tied to every internal system and vendor platform in response. Worth watching is whether any project that pulled version 1.107.0 between its release and PyPI's quarantine confirms it shipped the compromised build downstream, and whether LiteLLM reinstates its stricter, device-locked release-approval process now that the faster two-engineer rule has been shown to be exploitable with stolen credentials alone.

Sources