One Forgotten Key: LiteLLM Traces Malicious 1.107.0 Release to a Master Key Leaked on GitHub in May

LiteLLM has published the full attack chain behind the compromised litellm==1.107.0 release, and it starts with a key that was exposed five months earlier and never revoked.

The popular open-source AI gateway library pushed a malicious 1.107.0 release to PyPI, Docker Hub and GHCR on October 21, 2026. The release carried compiled malware that steals credentials and loads remote-code-execution tools. In a root-cause analysis published on October 23, LiteLLM said its investigation was complete and that the new post replaces earlier status updates, some of which turned out to be inaccurate.

How did the attacker get in? #

On May 27, 2026, a configuration file containing the master key to a deployment of the LiteLLM Agent Platform, an experimental tool LiteLLM used to orchestrate agents that file pull requests, was committed to the public LiteLLM-Labs/lite-harness repository. LiteLLM says the mistake was spotted quickly and the commit was force-pushed over, but the master key was never revoked.

That platform held a GitHub CLI OAuth token belonging to one of LiteLLM's GitHub organization owners. LiteLLM says the token was not tied to a service account and was not scoped down. GitHub CLI tokens are issued after two-factor authentication and are not subject to GitHub's re-authentication prompts for sensitive actions.

What happened next? #

All times below are UTC, from LiteLLM's timeline.

LiteLLM says its normal release flow requires approval from a special account locked to a physical device in its office. That rule had been relaxed earlier that week so any two engineers could trigger and approve releases for faster bugfix backports. The attacker used one stolen token to trigger the release and another to approve it. LiteLLM notes that with an org owner's token the attacker could have removed the restriction anyway, and believes separate tokens were used to keep audit logs quieter.

What changed from LiteLLM's first explanation? #

LiteLLM's first incident post suspected the GitHub tokens were taken from logs of an internal LiteLLM deployment, and described cases where Claude Code could embed a user's GitHub CLI token in a response body that might be logged. The October 23 analysis says request logs show the first token actually came from the Agent Platform API, as described above. LiteLLM has left the original post unchanged as a record but calls the new analysis the canonical account.

LiteLLM does not name the attacker. It describes the malware as stealing credentials and loading remote-code-execution tools, and says the attacker also went after tokens for internal systems, with a focus on upstream inference API keys.

Which artifacts were compromised? #

LiteLLM says the official 1.107.0 source tag on GitHub does not contain the malicious files, and that enterprise customers using its private registry were not affected. This is LiteLLM's second supply-chain compromise this year; its first incident post refers to a prior incident in March.

How did LiteLLM respond? #

LiteLLM says it locked its public registries, removed every member from its GitHub organization except one account it trusted, and began operating as if every token and key it owned had been stolen. It is revoking every token tied to its internal systems and vendor platforms, and says it will share process changes later. In its own words, the incident shows the risks of "failing to rotate a potentially exposed key."

What should LiteLLM users do? #

1. Check for exposure. If any environment ran litellm==1.107.0, or a container used the affected tags in the windows above, treat it as compromised. Search for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py.
2. Do not start Python first. LiteLLM warns that any Python start, including running pip, re-executes the malicious startup files. Delete cook.pth, cook.py, sitecustomize.py and matching cached files from the shell, and kill the detached daemon holding /tmp/remote_code_loader.lock.
3. Reinstall a pinned version. Pin to litellm==1.106.2 or another earlier explicit version; rebuilding images and virtual environments from scratch is better.
4. Rotate everything the host could reach. That includes cloud instance roles, every provider key stored in the LiteLLM proxy database, master and virtual keys, the database password and any secret in the host's environment.
5. Review cloud logs. Check for GetCallerIdentity calls from the instance role around install time and for use of its credentials from outside your infrastructure.
6. Learn the lesson for your own org. Scan repositories and history for committed secrets, revoke any exposed key immediately even if the commit is removed, and avoid giving automation tokens with owner-level, unscoped access.