Short answer
LiteLLM says an admin key committed to a public repository on 27 May 2026 was never revoked, and an attacker used it to reach maintainer tokens. On 21 October the attacker published litellm 1.107.0 to PyPI and container registries with a credential stealer. PyPI quarantined it within hours.
If you think your details were included, start with our checklist on what to do after a data breach.
Key facts
| Organization | LiteLLM |
|---|---|
| Incident type | Supply-chain compromise |
| Status | Confirmed by the organization |
| Sector | Open-source AI software |
| Country | United States |
| Detected | 2026-10-21 |
| Disclosed | 2026-10-21 |
| People or records affected | Anyone who installed or pulled litellm 1.107.0 or the affected Docker tags during the roughly two-hour window; no user count published |
What data was exposed
- Credentials collected from the machine running the package: cloud configuration, SSH and other private keys, AI provider keys, browser data and process environment variables, per Microsoft's analysis
- LiteLLM proxy database records, where the package could reach them
- LiteLLM's own internal GitHub tokens, CI secrets and some upstream provider keys
What happened
LiteLLM is an open-source gateway that lets developers call many AI model providers through one interface. On 21 October 2026 an attacker published a malicious version, litellm 1.107.0, to PyPI, Docker Hub and the GitHub container registry. LiteLLM published an incident post that day and a root cause analysis on 23 October.
How the attacker got in
According to LiteLLM, an administrative key for an internal Agent Platform deployment was committed to a public repository on 27 May 2026. It was removed from view within about three hours, but it stayed in the repository history until 22 October and was never revoked. The Hacker News reported the same account.
On 10 October, LiteLLM says, the attacker used that key to obtain a GitHub CLI token belonging to an organization owner. The attacker then used stolen maintainer tokens to pull CI secrets, with a second round of secret theft on 12 October. On 21 October the attacker overrode branch protection and changed the release workflow so it built from a lookalike fork named Berri-AI/litellm.
What the malicious package did
Microsoft’s analysis says version 1.107.0 added files that Python runs automatically at startup, so the code ran even if LiteLLM was never imported. The main component collected credentials from developer and AI tools, cloud configuration, browsers, SSH and other private keys and process environments. It encrypted the archive and uploaded it to an attacker-controlled endpoint. On Unix systems a separate loader could fetch more code. Microsoft did not confirm that any second-stage code ran.
Response
PyPI quarantined the release, and LiteLLM restored clean Docker tags. LiteLLM says it is revoking every token tied to its internal systems and vendor platforms. It says the attacker focused on upstream inference API tokens.
What to do if you use LiteLLM
Treat any machine that installed or pulled the affected artifacts as exposed. Microsoft advises checking installed environments, caches, internal mirrors, lock files and container images, and comparing them against the published hashes. Work from a clean system, then rotate every credential the machine could reach.
Stolen AI keys are often resold, and fake support messages follow. See our data breach checklist and the guide to phishing messages. A similar developer-platform incident is covered in the Railway secrets exposure.
Scams to watch for after this breach
Criminals use breach news as cover. Expect messages that mention the incident, quote real details, or offer help.
- Unauthorized use of stolen AI provider keys, followed by fake billing or 'refund' messages.
- Phishing that pretends to be a LiteLLM, PyPI or GitHub security notice and asks you to log in or paste a token.
- Attempts to log in to cloud or code accounts with stolen credentials, sometimes ending in extortion messages.
What to do if you are affected
- 01Check whether any environment, cache, mirror, lock file or container image installed litellm 1.107.0 or pulled the affected Docker tags on 21 October 2026.
- 02Do not run python or pip inside a suspect environment, because the payload ran at interpreter startup. Investigate from a clean system.
- 03Rebuild from verified artifacts. Deleting the litellm directory alone is not enough, according to Microsoft.
- 04From a clean machine, rotate model provider keys, cloud and CI secrets, source-control and registry tokens, and SSH keys, and revoke active sessions.
- 05Pin dependencies by hash and limit outbound network access from build and gateway hosts.
Frequently asked questions
Which LiteLLM version is malicious?
LiteLLM identifies litellm 1.107.0 as the malicious release. Docker tags v1.107.0, latest, main-latest and main-stable were also affected while they were available.
How long was it available?
LiteLLM's analysis puts publication at about 11:40 UTC on 21 October. PyPI quarantined the release at about 13:23 UTC, and Docker images were removed or repointed by about 14:20 UTC.
Was customer data taken from LiteLLM itself?
LiteLLM's analysis describes exposed credentials, tokens and CI secrets. It does not say that end-user data was taken. The risk to downstream users comes from what the malicious package could read on machines that ran it.
Has the attacker been identified?
No. LiteLLM and the sources cited here do not name the attacker. Microsoft also says it has not independently verified how the attacker obtained the developer credentials.
Sources
- LiteLLM 1.107.0 attack chain root cause analysis, LiteLLM, 2026-10-23
- Inside the LiteLLM 1.107.0 supply chain compromise, Microsoft Security Blog, 2026-10-23
- Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline, The Hacker News, 2026-10-24
This post summarises public reporting as of 2026-11-06. Details of live incidents change; we update posts when the organization or regulators publish new facts. Spot an error? See our editorial and corrections policy.