> ## Content Index
> Fetch the complete content index at: https://blog.harshkohli.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# LiteLLM Hack Traced to a Key Leaked in May
- URL: https://blog.harshkohli.com/litellm-attack-leaked-master-key/
- Published: 2026-10-24T14:56:08.000Z
- Updated: 2026-10-25T07:39:03.000Z
- Description: LiteLLM says a master key leaked in May and never revoked led to the poisoned 1.107.0 release. What happened and what to check now.
- Author: Harsh Kohli
- Tags: Tech News, AI

The poisoned LiteLLM release from earlier this week now has a clear origin story, and it's an uncomfortable one for anyone who has ever pushed a secret to GitHub by mistake. LiteLLM says a master key that leaked in May, and was never revoked, is what eventually let an attacker ship a malicious version of its Python package. I first saw the root cause in [a post from The Hacker News on X](https://x.com/TheHackersNews/status/2113951301059113271?ref=blog.harshkohli.com) and then read LiteLLM's own report.

## What happened

LiteLLM is a popular open-source gateway that lets apps call OpenAI, Anthropic and other model APIs through one interface. In its [attack chain write-up](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain?ref=blog.harshkohli.com), the team says a config file committed to a public repository on May 27 held the master key for an internal agent platform. The commit was force-pushed away, but the key itself was never revoked.

On October 10 the attacker used the key to pull a GitHub CLI token from that platform. The token belonged to a GitHub organisation owner and wasn't scoped down, so it opened every repo. From there the attacker ran short-lived workflows to collect the tokens of two maintainers. On October 21 they overrode branch protection, pointed the release job at a lookalike repo, and published `litellm==1.107.0` to PyPI plus Docker Hub and GHCR images. Earlier that week LiteLLM had relaxed its release gate so that any two engineers could trigger and approve a release, which the stolen accounts were enough to satisfy.

PyPI quarantined the release the same day. [Microsoft's analysis](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/?ref=blog.harshkohli.com) says the package dropped files that run whenever Python starts, even if LiteLLM is never imported, then steals credentials and opens an hourly backdoor.

## Why it matters

LiteLLM sits right next to the most valuable keys a developer holds, which is exactly why it was targeted. It's also a reminder that deleting a leaked secret from Git history does nothing. Once a key has been public for even a minute, you have to assume someone copied it. This is the same lesson as the [Railway breach](https://blog.harshkohli.com/railway-breach-rotate-api-keys/) from a few days ago, where AI API keys were again the prize.

## What to do

- Run `pip show litellm` on every machine, container and CI runner. If you ever installed 1.107.0, follow LiteLLM's [incident page](https://docs.litellm.ai/blog/security-incident-oct-21-2026?ref=blog.harshkohli.com) rather than just uninstalling, because the startup files sit outside the package folder.
- Treat that environment as compromised: rotate cloud keys, model API keys, SSH keys and package registry tokens it could reach.
- Pin LiteLLM to a known-good version and use hashes in your lock file.
- For your own projects, scope GitHub tokens to the repos they need, and revoke any key that ever lands in a public commit, even if you deleted it fast.