LiteLLM said attackers used stolen credentials from three developer GitHub accounts to hijack its release pipeline on Wednesday and publish a malicious version 1.107.0 to PyPI and Docker registries. The compromised build carried a credential stealer and a backdoor that can download and run remote code, according to LiteLLM's incident report, which as of 16:00 UTC said the incident was contained and the investigation still in progress.
The seven malicious wheels went up on PyPI between 11:39:51 and 11:40:13 UTC and were removed by 13:23, a window of about 1 hour 44 minutes. Compromised Docker Hub tags, including v1.107.0, latest, main-latest and main-stable, resolved to the bad image from 11:46:56 until 14:20 UTC, about 2 hours 34 minutes. Matching GHCR tags for the litellm, litellm-database and litellm-non_root images were unavailable by 13:51.
LiteLLM said the attack appears to have run on stolen GitHub CLI OAuth tokens. At 10:08 UTC, one account's credential overrode branch protection to change a private release workflow, which then built from an attacker-controlled repository named Berri-AI/litellm rather than the official source. A second account's credential satisfied the production approval gate at 11:11, and a third deleted production and staging workflow records shortly before noon, limiting the logs available to investigators.
Key facts
- 01Attackers used three LiteLLM developers' GitHub credentials to publish a malicious litellm 1.107.0 on October 21, 2026.
- 02The seven PyPI wheels were live from 11:39 to 13:23 UTC; affected Docker Hub tags stayed up until 14:20 UTC.
- 03The payload steals SSH, cloud, CI and LLM provider keys and installs an hourly remote-code loader.
- 04Version 1.106.2, the 1.107.0 release candidates and LiteLLM's private enterprise release are clean.
- 05LiteLLM says affected users should pin 1.106.2, rebuild environments and rotate every reachable secret.
The official v1.107.0 tag on GitHub does not contain the malicious files, and LiteLLM said all earlier versions are safe. Version 1.106.2 and the 1.107.0rc1 and rc2 release candidates were found clean, and customers running LiteLLM's private enterprise release were not affected.
The payload adds three files to site-packages: cook.pth, cook.py and sitecustomize.py. Because Python loads .pth files at startup, the code runs on every interpreter launch in the environment, even in processes that never import litellm. The stealer targets SSH and GPG keys, cloud credentials, CI/CD secrets, browser passwords, configs for more than 20 AI coding tools, and the provider API keys stored in a LiteLLM proxy database. It encrypts the haul with AES-256-CBC, wraps the key with RSA, and posts it to the lookalike domain litellm.dev.
The second stage is a background daemon that checks a file on a GitHub account named letters9813 every hour for a server address, then downloads and runs code from that host. When StepSecurity examined it, the file was empty, meaning that stage had not yet been armed. StepSecurity's timeline shows litellm.dev was registered on October 13 and the dead-drop repository was created on October 18.
AISLE said its dependency firewall flagged the first malicious wheel 3 minutes and 14 seconds after upload and had flagged all seven by 12:00:06 UTC. LiteLLM credited GitHub user LidorMachluf with helping detect the incident. StepSecurity noted this is the second LiteLLM compromise on PyPI this year, after versions 1.82.7 and 1.82.8 were hit in March using the same .pth startup technique.
LiteLLM says anyone who ran an unpinned pip install of litellm between 11:39 and 13:23 UTC, or pulled the affected Docker tags between 11:46 and 14:20 UTC, should assume they are compromised. Its guidance is to pin litellm==1.106.2, avoid running pip in an affected environment first because any Python start reruns the implant, delete the three planted files and their cached bytecode, kill the detached daemon holding the remote_code_loader lock file in /tmp, and preferably rebuild images and virtual environments from scratch.
Any host that installed 1.107.0 with outbound internet access should be treated as having had its data exfiltrated, according to LiteLLM. The project recommends rotating the instance IAM role, every provider key stored in the proxy database, master and virtual keys, the DATABASE_URL password and any secret in the host's process environments, then checking CloudTrail for GetCallerIdentity calls from the instance role around install time.
On its side, LiteLLM revoked every token involved, temporarily removed all but one unaffected user from its GitHub organization, cut trusted links between public registries and that organization, and reverted the unauthorized workflow. The project said it has not yet determined how the tokens were obtained, so it cannot yet assert that there is no further access to the affected accounts.
Working on something we should cover, or seeing a story we missed? Send leads, documents, or feedback to hello@aichatdaily.com. For sensitive tips, see our secure tips page for Signal and PGP options.
Spotted an error? Email hello@aichatdaily.com with the URL and the issue, or read our full corrections policy.
