# LiteLLM traces supply chain attack to a GitHub key nobody revoked > Source: > Published: 2026-10-26 20:38:11+00:00 # LiteLLM traces supply chain attack to a GitHub key nobody revoked A master key left active for 136 days gave an attacker the access needed to poison a LiteLLM release downloaded an estimated 49,000 times LiteLLM has traced its latest supply chain attack to a mistake made months earlier. According to the project’s postmortem, a master key exposed on GitHub was never revoked, and an attacker eventually used it to poison an official software release. The gap between the leak and the payoff was roughly five months. That is a long time for a door to sit unlocked, and it shows that attackers are patient. ## How the attack unfolded LiteLLM is an open-source Python library that acts as a router for AI models. Think of it as a universal remote: one interface that sends requests to multiple large language model providers, so developers do not have to wire up each one separately. The trouble started on May 27, 2026. A master key from an earlier experimental deployment was accidentally committed to a public repository. The key was never revoked, and it stayed active for 136 days. On October 10, an attacker put it to use. The intruder extracted sensitive tokens, including a GitHub CLI OAuth token, which opened the path to tampering with the repository’s CI workflows. CI workflows are the automated pipelines that build and publish software. Control those, and you can ship code that carries the project’s official stamp. That is exactly what happened on October 21, 2026. A compromised version, 1.107.0, went out through the Python Package Index (PyPI) and Docker registries. ## A two-hour window with outsized reach The malicious release was live for approximately two hours, from 11:39 to 13:23 UTC. That sounds brief, but popular packages move fast. ### AI, tech, and the markets they move—in one daily briefing. Daily. Free. Join 34,000+ readers across crypto, finance, and policy. An estimated 49,000 downloads of the poisoned package occurred before it was yanked from the platforms. The payload had two parts: a credential-stealing component and a remote code execution backdoor. The credential harvester, named “privcollect,” was designed to exfiltrate a range of sensitive API keys and credentials. The most unsettling detail is how it triggered. The malicious version ran automatically when Python started up, without anyone needing to import the library. Put more simply, developers did not have to call LiteLLM in their code to be exposed. Having the bad version installed in the environment was enough, and credentials could be compromised almost immediately. ## Second strike in one year This is not LiteLLM’s first rough patch in 2026. The October incident marks the project’s second supply chain attack of the year. The earlier breach came in March, when data was exposed through a compromised Trivy dependency. Two different entry points, same basic outcome: trusted software turned into a delivery mechanism. ## What this means for developers and the AI tooling market The immediate priority for anyone who installed version 1.107.0 is credential rotation. Because privcollect targeted API keys and other secrets, any key that lived in an affected environment should be treated as exposed. The bigger lesson sits upstream. The attacker did not need a zero-day exploit or a clever cryptographic trick. A key that should have been killed simply was not, and it stayed valid for 136 days after it went public. The postmortem itself is a useful step. Publicly tracing the chain from a forgotten key to a poisoned package gives other maintainers a concrete checklist: audit old deployments, revoke what is no longer needed, and treat CI access as crown-jewel infrastructure. For the roughly 49,000 downloads already out in the wild, though, the cleanup work is just getting started. **Disclosure:** This article was edited by Diego Almada Lopez. For more information on how we create and review content, see our [Editorial Policy](https://cryptobriefing.com/editorial-policy/).