Compromised LiteLLM 1.107.0 on PyPI installs a credential stealer and backdoor
A · Strong evidence SafeDep's technical teardown of a real supply-chain compromise gives a timed sequence, the injection mechanism, payload behaviour and indicators of compromise that responders can verify, cross-checked against LiteLLM's own incident report.
Summary based on the full text·Original: about 5 minutes to read
In short
A 21 October 2026 analysis by Kunal Singh of SafeDep of LiteLLM 1.107.0, a popular Python gateway for calling LLM providers, which shipped on PyPI with a credential stealer and a backdoor. The attacker used stolen GitHub CLI credentials of three LiteLLM developers to point the official release workflow at a lookalike repository, so the real pipeline built, signed and published the malicious artefacts. Both payloads ran in every Python process on an infected host, whether or not it imported LiteLLM.
Key numbers
- sevenmalicious LiteLLM 1.107.0 wheels (Linux, macOS, Windows) uploaded to PyPI
- 11:39 to 13:23 UTCwindow on 21 October 2026 between upload of the wheels and PyPI removing the release
- about 61 KBsize of the obfuscated Python credential stealer in cook.py
- every hourinterval at which the backdoor daemon re-ran the stealer and fetched remote code
As reported by the source.
English·Web page·opens safedep.io
What it reports
- All seven wheels installed three files into site-packages; a
.pthfile andsitecustomize.pymade the code run at every Python start. The upstream GitHub source did not contain them; the only visible sdist change was one extra build line. - The stealer collected SSH keys, cloud credentials, CI/CD secrets, browser passwords, Kubernetes tokens, AWS instance credentials, and tokens for AI coding tools (Claude Code, Cursor, Copilot, Gemini CLI, Codex and others). It also dumped the LLM provider API keys stored in a LiteLLM proxy database. Data was encrypted and posted to an attacker server.
- The backdoor ran as a detached daemon that every hour read a server address from a GitHub file, re-ran the stealer and downloaded and executed code. The attacker's GitHub account returned 404 at 13:40 UTC, about two hours after release; hosts that ran the daemon before then may have received second-stage code.
- Timeline (UTC, 21 October): 10:08 branch protection overridden; 11:39 to 11:40 wheels uploaded; 11:46 malicious Docker images published; 13:23 PyPI removal; 14:20 Docker tags repointed.
- Versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean. LiteLLM believes the credentials came from logs of an internet-exposed internal deployment.
- The post lists network and host indicators, image digests and file hashes.
How they got it
Static analysis of the published sdist, wheels and decoded payloads, with the release timeline taken from LiteLLM's incident report and SafeDep's own observation of the attacker account.
Limits
- No download counts or number of affected hosts.
- SafeDep could not recover the second-stage server address, so what was delivered after initial infection is unknown.
- How credentials leaked rests on LiteLLM's belief, not a final finding.
- SafeDep sells tools that block malicious packages.
Why it matters for companies
LLM gateways concentrate provider keys for a whole organisation, which makes them a high-value target; this attack went straight for those keys and for AI coding-tool tokens on developer machines. A signed release from the official pipeline was malicious, so provenance checks alone would not have stopped it. Companies should pin and review dependency upgrades, rotate any keys on hosts that installed 1.107.0, and keep provider keys out of developer laptops and logs.
Summary based on the full text. Read the original for the full argument and data.Read the original on safedep.io
- Tags
- AI security, Supply chain