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 reported.
LiteLLM is an open-source Python gateway that gives applications a single interface to many large language model providers, as Digital Today 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.
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 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 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 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. 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 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 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 to the vendor breach that PwC confirmed. 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.
