# LiteLLM Master Key Leak Enabled a Malicious 1.107.0 Release on PyPI

- URL: https://usa-24.com/litellm-master-key-leak/
- Publisher: USA 24
- Section: Cybersecurity
- Published: 2026-10-25T02:26:35.054Z
- Updated: 2026-10-25T02:26:35.065Z
- Topics: Supply Chain Attack, Credential Theft, Developer Security, GitHub Security, Open Source Security

> A master key left unrevoked for 136 days let an attacker reach LiteLLM's release pipeline and publish a poisoned 1.107.0 package to PyPI and Docker Hub.

## Key takeaways

- LiteLLM's master key was committed to a public GitHub repository on May 27, 2026, and it stayed valid for 136 days after the exposure.
- An attacker used the key on October 10 to pull a GitHub CLI OAuth token tied to an organization owner, then harvested tokens from two maintainers.
- Malicious LiteLLM 1.107.0 was published to PyPI, Docker Hub and GHCR on October 21, and PyPI quarantined the release.
- Any team that pulled 1.107.0 should treat that host as compromised and rotate cloud, AI-provider, GitHub and CI/CD credentials.
- Sources conflict on whether the master key was revoked, and the reported theft of Anthropic, OpenAI, AWS Bedrock and Together AI keys remains unverified.

The LiteLLM master key leak began on May 27, 2026, when a configuration file containing a live master key landed in a public GitHub repository. The team force-pushed over the commit and flagged the key for revocation. LiteLLM's root-cause analysis says the key was never actually revoked, and it stayed valid for 136 days.

In October, an attacker used that key to reach the release pipeline behind the open-source project. A poisoned 1.107.0 package went out to PyPI, Docker Hub and GHCR on October 21. LiteLLM published a root-cause analysis on Friday, October 23, that explains how the release happened and why the exposure lasted months, as [The Hacker News](https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html) reported.

LiteLLM is an open-source Python gateway that gives applications a single interface to many large language model providers, as [Digital Today](https://www.digitaltoday.co.kr/en/view/119081/litellm-deployment-system-compromised-after-admin-key-exposed-by-mistake) describes it. That reach is why a poisoned release matters to developers building AI apps. USA 24 has already covered the 1.107.0 malware itself, so this story focuses on how the attacker got in and what the disclosure changes.

This is a supply-chain attack, and it did not start with a break into LiteLLM's source code. The attacker moved from one leaked secret to a trusted release workflow. Developer tools keep running into this pattern, and the LiteLLM case shows how long the window can stay open.

## How a public GitHub commit became a live master key

The exposed file sat in the public LiteLLM-Labs/lite-harness repository, where anyone could read it. In its root-cause write-up, LiteLLM's Oliver Jensen and Mateo Wang said the file "inadvertently contained the master key to a deployment of the LiteLLM Agent Platform," as The Hacker News reported. Jensen is LiteLLM's Director of Security and Wang is an AI engineer, according to [WebProNews](https://www.webpronews.com/litellm-1-107-0-attack-chain-unrevoked-master-key).

The response missed the step that mattered most. The team force-pushed over the commit and flagged the keys for revocation, but the master key stayed valid. Rewriting history removes a file from the branch, but it does not reach every copy. As the [DEV Community analysis](https://dev.to/etairos/leaked-litellm-master-key-sat-unrevoked-for-136-days-then-shipped-a-malicious-11070-release-43k3) points out, removing a commit does not remove copies held by clones, mirrors or scrapers.

That is the core lesson of this incident. A flagged credential remains a live credential until someone revokes it. Teams that have used leaked secrets should revoke them right away instead of only deleting the file that held them.

## How the LiteLLM master key leak reached the release pipeline

On October 10, an attacker at IP address 69.48.229.143 used the key to access the Agent Platform, according to LiteLLM's account. From there, the attacker pulled a GitHub CLI OAuth token. That token was not scoped down. It belonged to a GitHub organization owner's account, which gave the attacker owner-level access to the organization's repositories.

The same pattern shows up elsewhere. USA 24 reported on a [Microsoft 365 token replay campaign](https://usa-24.com/microsoft-365-token-replay-attack/) in which stolen tokens breached 79 organizations without passwords.

Within minutes, throwaway workflows on internal branches of the BerriAI/litellm and BerriAI/litellm-auto repositories harvested tokens from two maintainers and sent them to a webhook.site endpoint. [LAVX News](https://news.lavx.hu/article/leaked-litellm-master-key-lets-attackers-hijack-release-pipeline-publish-malicious-package) reports that the malicious workflows ran between 10:11 and 10:12 p.m. UTC.

A second malicious commit followed on October 12. LiteLLM says a developer credential overrode branch protection on its private release workflow, according to [Brandefense](https://brandefense.io/security-news/litellm-1-107-0-supply-chain-attack-what-to-do/). That override put the malicious code on the path to publication.

Malicious LiteLLM 1.107.0 went out on October 21 to PyPI, Docker Hub and GHCR. PyPI quarantined the release, and Docker Hub tags were removed or repointed to clean images, according to the DEV Community analysis.

## Which LiteLLM 1.107.0 installs are at risk

Anyone who installed or updated LiteLLM from PyPI or Docker between October 21 and the end of the cleanup window may have run the stealer. The timeline below shows the dates that matter.

| Date | What happened |
|---|---|
| May 27, 2026 | Master key committed to the public LiteLLM-Labs/lite-harness repository |
| October 10, 2026 | Attacker uses the key, pulls a GitHub CLI OAuth token, and harvests maintainer tokens |
| October 12, 2026 | Second malicious commit lands |
| October 21, 2026 | Malicious LiteLLM 1.107.0 published to PyPI, Docker Hub and GHCR |
| October 23, 2026 | LiteLLM publishes its root-cause analysis (some outlets date it October 24) |

Per Socket's analysis, as cited by Brandefense, the stealer reads credentials for AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault and Terraform. Those stores hold the secrets that build and deployment hosts depend on, so one affected machine can expose a lot.

Organizations that ran the Agent Platform, or that used GitHub tokens tied to LiteLLM's organization, may have exposed cloud, AI and repository credentials too.

A DEV Community summary goes further and says the attacker harvested API keys for Anthropic, OpenAI, AWS Bedrock and Together AI. That is a secondary report. None of the reporting reviewed for this story includes a primary LiteLLM statement confirming those keys were taken, so treat the claim as unverified.

## What to do now if you installed LiteLLM 1.107.0

These steps come from the practical guidance in the coverage, and none of them wait on the open questions.

- Search every environment for LiteLLM 1.107.0, including laptops, CI runners, containers and cloud build hosts. Check Docker images pulled from Docker Hub or GHCR as well as PyPI installs.
- If an environment pulled 1.107.0, treat that host as compromised. Do not just upgrade in place.
- Rotate cloud, AI-provider, GitHub and CI/CD credentials that the host could reach.
- Pin dependencies to verified clean versions instead of floating ranges, so a later release cannot slip in unnoticed.
- Audit GitHub organization owner accounts and OAuth grants, and remove any token that does not need owner-level access.
- If your team ran the LiteLLM Agent Platform, treat its master key as exposed and replace it. Revoke any secret that appeared in a repository, even after the file was removed.

Keep a record of what you checked and when. If you find evidence that the stealer ran, bring in your incident response process before you start cleaning up.

## What the conflicting reports leave unresolved

Several details differ across the coverage. The biggest is whether the master key was revoked. LiteLLM's root-cause account says it was not, and it stayed valid for 136 days. A [Privacy Needle article](https://privacyneedle.com/cybersecurity/litellm-master-key-leak-supply-chain-attack/) reports that LiteLLM revoked it. The root-cause account carries more weight because it comes from LiteLLM itself, but the reporting reviewed here does not resolve the discrepancy.

The disclosure date also varies. The Hacker News reports the root-cause analysis as published on Friday, October 23, while other outlets date it October 24. The sources reviewed do not identify the attacker, and the number of downstream users who installed 1.107.0 remains unknown.

Separately, CISA added a different LiteLLM flaw, CVE-2026-59822 (improper authentication), to its Known Exploited Vulnerabilities catalog on September 2, 2026, as its [alert](https://www.cisa.gov/news-events/alerts/2026/09/02/cisa-adds-seven-known-exploited-vulnerabilities-catalog) shows. Reports do not tie that flaw to this incident, and the coverage reviewed does not say whether the two are connected.

## What comes next for LiteLLM and developer secrets

Credential theft keeps appearing across the sector, from [k0t hackers' harvest of 70,000 credentials from FortiGate and GlobalProtect](https://usa-24.com/fortigate-credentials-stolen-k0t-campaign/) to the [vendor breach that PwC confirmed](https://usa-24.com/pwc-data-breach-everest-590-gb/). USA 24 has also covered earlier breaches at developer platforms such as Railway, Zeabur and PingCAP. Maintainers should verify that revocation actually completed, check which tokens can reach release workflows, and treat any leaked secret as live until proven otherwise.

Watch for two things. First, a full post-incident report from LiteLLM that settles the revocation question and says whether the downstream API keys were taken. Second, cleanup disclosures from PyPI and Docker Hub, which may show how many environments pulled 1.107.0.

## Frequently asked questions

### How do I know if I have LiteLLM 1.107.0 installed?

Check every environment that installs Python packages, including laptops, CI runners, containers and cloud build hosts, for LiteLLM 1.107.0. Check Docker images pulled from Docker Hub or GHCR too. If any environment pulled 1.107.0 on or after October 21, treat that host as compromised. Plain version checks are a starting point, not a full investigation.

### Should I rotate my LiteLLM API keys after this incident?

Yes, if any environment that touched LiteLLM 1.107.0 or the Agent Platform was exposed. Rotate cloud, AI-provider, GitHub and CI/CD credentials that the host could reach. Socket's analysis, as cited by Brandefense, says the stealer reads AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault and Terraform credentials. Treat reported theft of AI-provider API keys as unverified until LiteLLM or a primary investigator confirms it.

### Was the leaked LiteLLM master key revoked?

Sources disagree. LiteLLM's root-cause account says the key was not revoked and stayed valid for 136 days after it was exposed on May 27, 2026. A Privacy Needle article reports that LiteLLM revoked it. Until the conflict is resolved, assume the key was live and replace it.

### Is CVE-2026-59822 part of the LiteLLM supply chain attack?

CISA added CVE-2026-59822, an improper authentication flaw in LiteLLM, to its Known Exploited Vulnerabilities catalog on September 2, 2026. Reports reviewed for this story do not tie that flaw to the 1.107.0 incident. Teams running LiteLLM should check their versions against both issues.

## Sources

1. [Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline](https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html)
2. [LiteLLM 1.107.0 Compromised: What to Do Now](https://brandefense.io/security-news/litellm-1-107-0-supply-chain-attack-what-to-do/)
3. [Leaked LiteLLM Master Key Sat Unrevoked for 136 Days, Then Shipped a Malicious 1.107.0 Release](https://dev.to/etairos/leaked-litellm-master-key-sat-unrevoked-for-136-days-then-shipped-a-malicious-11070-release-43k3)
4. [LiteLLM Traces Its Poisoned 1.107.0 Release to a Master Key Nobody Revoked](https://www.webpronews.com/litellm-1-107-0-attack-chain-unrevoked-master-key)
5. [Leaked LiteLLM Master Key Lets Attackers Hijack Release Pipeline, Publish Malicious Package](https://news.lavx.hu/article/leaked-litellm-master-key-lets-attackers-hijack-release-pipeline-publish-malicious-package)
6. [LiteLLM Master Key Leak Triggers Supply Chain Attack](https://privacyneedle.com/cybersecurity/litellm-master-key-leak-supply-chain-attack/)
7. [LiteLLM deployment system compromised after admin key exposed by mistake](https://www.digitaltoday.co.kr/en/view/119081/litellm-deployment-system-compromised-after-admin-key-exposed-by-mistake)
8. [CISA Adds Seven Known Exploited Vulnerabilities to Catalog (Sept. 2, 2026)](https://www.cisa.gov/news-events/alerts/2026/09/02/cisa-adds-seven-known-exploited-vulnerabilities-catalog)