LiteLLM release pipeline hacked: version 1.107.0 shipped credential-stealing malware

What this is about

LiteLLM is an open-source Python SDK and "AI gateway": applications talk to models from different providers through a single unified interface. The project is hugely popular – according to BleepingComputer, it has about 61,800 GitHub stars and 92 million monthly downloads on PyPI (the Python package index). It's used by companies including NVIDIA, Netflix, AT&T and Okta.

On October 21, the project's release pipeline was hijacked. An attacker published version 1.107.0 on PyPI and in the Docker registries. According to the maintainer, it contained "compiled malware that steals credentials and pulls in remote code execution tooling." This is known as a supply chain attack: instead of hacking the target system directly, attackers tamper with software it trusts.

Affected artifacts and time windows

• PyPI: litellm==1.107.0, all seven wheels (prebuilt installation packages), live from 11:39 to 13:23 UTC.
• Docker Hub: v1.107.0, latest, main-latest and main-stable pointed to a compromised image from 11:46 to 14:20 UTC.
• GHCR (GitHub Container Registry): the same tags for litellm, litellm-database and litellm-non_root, from 11:46 UTC until they were blocked around 13:51 UTC.

So if you pulled "latest" that day, you may be affected. According to BleepingComputer, several security firms detected the attack within six minutes of publication.

How the malware works

The attacker didn't change the application code, only the installation package. It dropped three files into the Python library directory: cook.pth, cook.py and sitecustomize.py. On normal startup, Python executes lines in .pth files and imports sitecustomize. As a result, the malware runs on every Python start – even if the application never imports LiteLLM. Even launching Python or pip to investigate triggers the malware again.

It searched for:

• Cloud and deployment credentials (AWS, Azure, Google Cloud, Kubernetes, Docker)
• AI credentials, plus provider keys and model settings stored in LiteLLM
• Developer secrets: Git, GitHub, npm, PyPI, CI/CD (GitLab, Jenkins), .env files, SSH, GPG and TLS keys
• Browser data (logins, cookies, autofill, history)
• Environment variables, shell histories, system and network information

The data is encrypted with AES-256-CBC, the key with RSA-4096, and then uploaded to litellm[.]dev/healthcheck. In addition, sitecustomize.py launches a detached loader that checks a GitHub-hosted pointer every hour and executes Python code from an external server. According to Aikido, this is effectively a remote access trojan: the attackers can keep running commands even after the theft.

How the attackers got in

According to LiteLLM's incident report, the attackers used stolen GitHub credentials from three developer accounts. With them, they modified the release workflow and redirected it to a lookalike repository under their control. The credentials may have come from logs of an internet-reachable internal LiteLLM installation. The project also describes circumstances in which Claude Code could expose GitHub tokens in responses, which LiteLLM then logged. How the attackers originally gained access to that installation is unclear.

The twist: after the March attack (which came via Aqua Security's Trivy security scanner, used by LiteLLM in its CI/CD pipeline; the TeamPCP group published malicious versions), the project had moved releases to a private repository and introduced signed Docker images. This time, the tampered workflow signed the malware itself. A valid signature only proves that an artifact is unchanged since it was signed – not that the code was harmless when it was signed.

What affected users should do

• Stop affected deployments and inspect environments without launching the Python interpreter or pip.
• Isolate infected systems and rebuild them from clean backups; preserve forensic evidence first.
• Rotate all reachable secrets immediately (cloud, CI/CD, provider keys).
• Simply deleting the LiteLLM directory isn't enough; startup files or the loader may remain.
• Recommended version: LiteLLM 1.106.2. Customers of the private Enterprise registry were not affected, according to the project.
• Check packages and image digests in production, on developer machines and on CI runners; review logs for misuse of credentials and compare AI usage data against cloud audit logs.

Our take

An AI gateway bundles keys for many models and services, which makes it a lucrative target. Sakshi Grover (IDC) says it is privileged infrastructure: centralization improves governance, but it also concentrates trust. Keith Prabhu (Confidis) stresses that a trustworthy source repository doesn't guarantee that the installed package was built from it. Recommended measures include verifiable build provenance, better-protected publishing credentials, restricting installs to vetted digests, and independent approval for changes to release workflows.

It remains unclear how many systems were actually infected and how the initial access happened. According to Grover, missing indicators don't prove that an environment is clean. The short window of about two hours limits the risk, but with 92 million monthly downloads it's far from negligible.