LiteLLM malicious package 1.107.0 stole credentials
The LiteLLM malicious package released as version 1.107.0 harvested credentials and installed a backdoor capable of fetching and running Python code every hour. LiteLLM disclosed on Wednesday that attackers had bypassed several independent security controls and compromised its release pipeline, the automated process used to build and publish software.
The poisoned release was published on October 21, 2026, at around 4:00 a.m. PST. It appeared as LiteLLM v1.107.0 on the Python Package Index (PyPI), the main public repository for Python software. Docker Hub and GitHub Container Registry (GHCR) received images carrying the tags v1.107.0, latest, main-latest and main-stable. LiteLLM said enterprise customers using its private image registry were not affected and that the compromised version was removed within three hours.
Users are considered affected if they installed an unpinned LiteLLM package through pip between 11:39 a.m. and 1:23 p.m. UTC, or pulled one of the listed container images between 11:46 a.m. and 2:20 p.m. UTC. An unpinned installation allows the package manager to select an available version instead of requiring one exact release. Because commonly used tags such as latest were poisoned, teams could have received the malicious build without explicitly requesting version 1.107.0.
The malicious code collected secrets associated with the operating system, browsers, development tools, cloud services and artificial intelligence tools. It sent the stolen data in an HTTP POST request to litellm[.]dev/healthcheck. It also created a remote access trojan (RAT), malware that allows an outside operator to run code on the compromised system.
The infection was embedded in the package rather than LiteLLM's application source. Endor Labs reported that a single addition to the Maturin build configuration placed cook.pth, cook.py and sitecustomize.py into the Python library directory. Python processes .pth configuration files and imports sitecustomize during startup, so the payload could activate whenever Python started in that environment, even when the running application did not use LiteLLM. The cook.pth file imported cook.py, which decoded itself and launched a routine called privcollect to gather and transmit secrets.
On Linux and macOS, sitecustomize.py also attempted to retrieve domain.txt from a now-removed GitHub account at github[.]com/letters9813. If the file supplied a usable address, the malware downloaded a second Python program from /codepy and executed it. Aikido found that the loader started a background process, used /tmp/remote_code_loader.lock to avoid duplicate copies, and repeatedly checked raw[.]githubusercontent[.]com/letters9813/pythonclient-test/main/domain[.]txt for the attacker's current command server. It then requested and ran a new payload every hour. Wiz said the file contained only initial test values before GitHub removed it at about 1:30 p.m. UTC. Wiz described the simultaneous use of .pth and sitecustomize.py as the first documented combination of those two Python startup methods in active malware.
Wiz subsequently observed use of stolen AWS instance-role credentials from compromised continuous integration (CI) runners, which are systems that automatically build and test software, and Kubernetes nodes. The activity began roughly 4.5 hours after the secrets were transmitted. Between 4:20 p.m. and 5:01 p.m. UTC, connections from 168.100.8[.]57 and 165.227.201[.]8 checked credentials with sts:GetCallerIdentity, then called bedrock:ListFoundationModels and ListModels. Wiz said that sequence was consistent with LLMjacking, the unauthorised use of another organisation's cloud access to consume artificial intelligence services. In a small number of environments, the attacker also listed AWS roles, users and access credentials, and queried accounts and audit-trail settings.
LiteLLM had previously changed its release process after a separate incident in March 2026. Those measures included moving releases to a private repository, making Docker release tags immutable so they could not be reassigned, and cryptographically signing images. On October 19, however, maintainers temporarily extended release permissions to two internal engineers who needed to publish daily customer bug-fix backports. The attacker had obtained three sets of developer GitHub command-line credentials, including one able to start GitHub workflows.
According to LiteLLM's investigation, a credential belonging to a GitHub organisation owner was used to disable branch protections and force malicious changes into the project. The attacker then ran the workflow against a lookalike repository named Berri-AI/litellm rather than the legitimate BerriAI/litellm repository. That caused the compromised packages and images to pass through the project's signing and publishing process.
LiteLLM said it had observed situations in which Claude Code placed a user's GitHub CLI OAuth token into a response body. An OAuth token is a reusable account credential that lets software act with permissions granted by the user. If response bodies were recorded, the token could consequently appear in LiteLLM logs. Maintainers also found an unexpected, harmless-looking user account in an internal LiteLLM deployment that was reachable from the public internet. They suspect the attacker accessed that system and recovered GitHub credentials from its logs. How the deployment became public and how access was obtained remain unclear. LiteLLM has suggested a recently patched vulnerability may have been involved, but its root-cause investigation is continuing.
The use of a .pth file resembles the technique seen in the March attack attributed to TeamPCP, but Socket said the available evidence does not establish a connection. Socket noted differences in the embedded cryptographic RSA public keys, data-theft implementation and backdoor behaviour. It also remains unverified whether credentials stolen during the March incident contributed to the October compromise.
Organisations that ran LiteLLM 1.107.0 should remove it, disconnect affected hosts from other systems, search for the three malicious Python files, block the data-collection domain and investigate any execution of /codepy. All credentials reachable from an affected environment should be revoked and replaced, including cloud, developer and browser-held secrets. JFrog advised rebuilding affected systems and verifying the exact Python wheel, which is the installable package file, rather than assuming a clean source repository guarantees a clean published artifact. Endor Labs also recommended reviewing network records and pinning container images by digest, a fixed identifier for exact image contents, instead of a changeable tag.
For organisations that need assistance with the wider infrastructure response to incidents of this kind, AEU-I provides security-first IT, infrastructure and consulting.