LiteLLM root cause: a leaked key was force-pushed, not revoked

The LiteLLM supply chain attack started five months before the bad release. LiteLLM's attack chain write-up says a master key landed in a public GitHub repo on May 27, 2026. The team force-pushed over the commit. The key was never revoked. On October 10, an attacker used it. On October 21, a poisoned litellm==1.107.0 shipped to PyPI and container registries. We covered the cleanup for 1.107.0 last week. This is the root cause, and it applies to every team that has ever committed a secret.

What actually happened

Per LiteLLM's own post, published October 23:

• May 27: an opencode.json file with a LiteLLM Agent Platform master key was committed to the public LiteLLM-Labs/lite-harness repo. In LiteLLM's words, "the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key."
• October 10: the attacker used the key to get into the Agent Platform and pull a GitHub CLI OAuth token. The token belonged to one of two GitHub organization owners.
• That week: release approval normally needed an engineer plus a locked-down approval account. LiteLLM had relaxed it so "any two engineers" could trigger and approve a release.
• October 21: with stolen tokens, the attacker repointed the release pipeline and published 1.107.0.

The Hacker News adds that malicious workflows on throwaway branches collected more secrets on October 10 and 12, including keys for Anthropic, OpenAI and AWS Bedrock. LiteLLM says it is now revoking every token tied to its internal systems and vendor platforms.

Why a leaked secret is a business problem, not a Git problem

A force-push hides the secret. It does not kill it. Public commits get cloned, cached and scraped in minutes. Once a key is public, the only fix is to revoke it at the issuer and confirm the old value fails. Rewriting history is cleanup, not response.

One owner token was the whole org. An unscoped OAuth token on an owner account reached every repo. Your automation should not run as the person who owns the GitHub org.

Relaxed controls are the window. The release rule was loosened for speed the same week it mattered. If you loosen a control, put an end date on it.

Do this this week:

1. Turn on GitHub secret scanning and push protection on every repo.
2. Keep a list of every key and who can revoke it, so a leak response takes minutes.
3. When a secret leaks, revoke first, test that the old value fails, then rewrite history.
4. Move CI and bots to fine-grained tokens or GitHub Apps, not owner accounts.

Sources: LiteLLM: Security incident attack chain, The Hacker News.