Was LiteLLM compromised?

Yes, twice in 2026. On 21 October, litellm 1.107.0 was published to PyPI and to Docker Hub and GHCR with compiled malware that steals credentials and loads remote-code tools. On 24 March, versions 1.82.7 and 1.82.8 were published to PyPI with a credential harvester. In both cases the GitHub source was clean: the malicious files were only in the published packages.

Which LiteLLM versions are malicious?

1.107.0 (PyPI, 21 October 2026, 11:39 to 13:23 UTC, plus the Docker tags v1.107.0, latest, main-latest and main-stable until 14:20 UTC), and 1.82.7 and 1.82.8 (PyPI, 24 March 2026). LiteLLM says every earlier version is safe and recommends pinning to 1.106.2 or another explicit earlier version.

How do I know if I installed LiteLLM 1.107.0?

Run pip show litellm, search lockfiles and CI logs for 1.107.0, and check whether any container ran the litellm image with the latest, main-latest or main-stable tag on 21 October. LiteLLM also lists the files litellm-1.107.0.dist-info, cook.pth and sitecustomize.py as markers. Finding them confirms exposure; not finding them does not prove the machine is clean.

What should I do if I ran LiteLLM 1.107.0?

Do not just reinstall: the malicious files run again at every Python start. Rebuild the environment or image from scratch on a pinned clean version, assume anything the host could reach was stolen, and rotate it: cloud roles, every model provider key stored in the proxy, master and virtual keys, the database password and any secret in the environment. Then look for those credentials being used from outside your infrastructure.

Does the LiteLLM supply chain attack affect the proxy or the library?

Both. The PyPI package is what you get when you import litellm in your own Python code, and the Docker images are what most teams run as the LiteLLM proxy. It also reaches you indirectly: other tools bundle LiteLLM as a dependency, so check what your developer tools and AI agents install, not just your own code.

LiteLLM Supply Chain Attack (1.107.0): Check and Clean Up

A conveyor belt carrying software packages from a factory to a server, one box cracked open with a small spider-like device reaching for a set of keys, and a locked gate at the end letting only a sealed, tagged box through

On 21 October 2026, LiteLLM 1.107.0 was published to PyPI and to Docker Hub and GitHub's container registry with compiled malware that steals credentials and loads remote-code tools. The PyPI release was live from 11:39 to 13:23 UTC, and the latest, main-latest and main-stable Docker tags pointed at the bad image until 14:20 UTC (LiteLLM's incident report). Wiz counts roughly 49,000 downloads of the malicious version (Wiz). It is LiteLLM's second supply chain attack this year, after versions 1.82.7 and 1.82.8 in March. If 1.107.0 ran anywhere, removing it is not enough: rebuild and rotate. We run LiteLLM in production, so below is how to check, what to rotate, and what we found when we checked our own stack.

What happened on 21 October

LiteLLM's own timeline, all times UTC:

Time	Event
10:08	A privileged developer credential overrides branch protection and changes the release workflow
10:46	A staging run builds from a lookalike repository, `Berri-AI/litellm`
11:11	A second developer credential approves the production release
11:39	Seven malicious 1.107.0 wheels uploaded to PyPI
11:46	Malicious images published to Docker Hub and GHCR
11:53	A third credential deletes the workflow records
13:23	PyPI removes 1.107.0
14:20	All affected Docker Hub tags removed or repointed to clean images

The official v1.107.0 source tag on GitHub does not contain the malicious files. The packages were built from the attacker's copy. LiteLLM says the attackers had GitHub CLI OAuth tokens belonging to its engineers, and that the way in is still under investigation. Datadog and SOCRadar report stolen AWS credentials already being used afterwards (Datadog, SOCRadar).

Affected artifacts:

PyPI: litellm==1.107.0, all seven wheels.
Docker Hub and GHCR: the tags v1.107.0, latest, main-latest and main-stable, including the litellm-database and litellm-non_root images on GHCR.
Not affected: enterprise customers on LiteLLM's private registry, and every version before 1.107.0.

March and October: two attacks, one lesson

	March 2026	October 2026
Versions	1.82.7, 1.82.8	1.107.0
Where	PyPI	PyPI, Docker Hub, GHCR
How	Stolen PyPI publishing credentials, reportedly via the compromised Trivy scanner in CI	Stolen developer GitHub tokens, release pipeline pointed at a lookalike repository
Payload	Harvester for SSH keys, cloud credentials, Kubernetes secrets, .env files	Compiled credential stealer plus remote-code loader
Live for	Three to five hours, by reports	1 h 44 on PyPI, about 2.5 h on Docker Hub

Both times, the source code on GitHub was clean and the published package was not. Reading the code before upgrading would not have caught either one. What protects you is not installing a new version the hour it comes out, and never letting a production build pull a floating tag like latest. We covered the March incident, and LiteLLM's separate MCP authentication flaw, in our LiteLLM vulnerability post.

How to check whether you are affected

Lockfiles and CI logs. Search uv.lock, poetry.lock, requirements*.txt and build logs for litellm 1.107.0 (and 1.82.7 or 1.82.8).
Running environments. pip show litellm on every machine and image that has Python.
Containers. Did anything pull litellm with the latest, main-latest, main-stable or v1.107.0 tag on 21 October? Check pod and deployment history, not just what runs today.
Markers. LiteLLM lists litellm-1.107.0.dist-info, cook.pth and sitecustomize.py in site-packages. Finding them confirms exposure. Not finding them does not prove the machine is clean.
Indirect installs. Developer tools, notebooks, coding agents, MCP plugins and AI code review bots often bundle LiteLLM. Check what they installed on 21 October too.

If 1.107.0 ran: clean up in this order

From LiteLLM's remediation steps:

Do not start with pip install. The malicious files run again every time Python starts.
Rebuild the environment or image from scratch, pinned to litellm==1.106.2 or another explicit earlier version. If you must clean in place, remove cook.pth, cook.py, sitecustomize.py and their compiled .pyc files, and stop the background Python process holding /tmp/remote_code_loader.lock.
Assume data left the machine if it had outbound internet access.
Rotate what the host could reach: the instance or task cloud role, every model provider key stored in the proxy database, master and virtual keys, the DATABASE_URL password, and any secret in the process environment.
Look for reuse. In AWS, check CloudTrail for GetCallerIdentity calls from the instance role around install time, and for those credentials being used from outside your infrastructure.

What we found in our own stack

We checked two places where LiteLLM runs in our infrastructure:

Our AI service calls models through the LiteLLM library. It installs from a lockfile that has pinned 1.90.2 since 3 July 2026, and that lockfile has not changed since. 1.107.0 was never installed.
Our self-hosted AI code review bot bundles LiteLLM as a dependency, version 1.81.12, inside an image we mirrored from Docker Hub on 3 June 2026 and pin by tag. It never pulls latest, so it never saw the bad image.
The March attack did not reach us either. Our AI service's lockfile had LiteLLM pinned at 1.80.0 throughout March, so 1.82.7 and 1.82.8 were never installed. On 10 April we moved to 1.83.4 and set the minimum to >=1.83.0, with a comment in the dependency file saying it skips the compromised versions.

Neither result is luck exactly. A lockfile, a pinned image tag and nobody upgrading on the day of a release are boring habits. They are also the whole defence against this class of attack, because the code everyone reads on GitHub was clean both times.

What we have not done: we do not run the LiteLLM proxy, so we cannot speak to cleaning one from experience. The steps above are LiteLLM's.

LiteLLM Supply Chain Attack: 1.107.0 Was Compromised, Again

On 21 October 2026, LiteLLM 1.107.0 went out on PyPI and Docker Hub with a credential stealer inside. It is the second time this year. Here is what was affected, how to check your machines and images, what to rotate, and what we found in our own stack.