LiteLLM 1.107.0 Was Compromised: What to Check Before You Reinstall

If your team installed LiteLLM 1.107.0, check which builds and servers used it. LiteLLM says an attacker compromised its release pipeline on 21 October 2026 and published malicious packages.

The difficult part is the cleanup. Removing the package may leave malicious files behind, and replacing the software does not invalidate credentials that were already stolen.

What was affected?

The maintainer’s report identifies malicious PyPI wheels for version 1.107.0 and affected container releases, including v1.107.0, latest, main-latest, and main-stable during the incident’s exposure window. The artifacts were subsequently removed or repointed.

A wheel is the packaged Python code your installer downloads. A container tag such as latest is a label that can point to different images over time.

That distinction matters here. The maintainers say the official GitHub source tag did not contain the malicious files. Reviewing that source alone would not tell you whether a downloaded package was safe. They also say customers using the private enterprise registry were unaffected.

Start with the maintainer’s incident report for the current scope and recovery instructions.

Why isn’t uninstalling enough?

The malicious release could place files in Python’s startup path. Python can load those files when it starts, before your application explicitly imports LiteLLM.

Wiz identifies files including cook.pth and sitecustomize.py. Its researchers describe credential theft and the ability to load more code, with targets including cloud credentials, developer secrets and AI provider keys. They also report observed use of stolen credentials. These findings do not establish what happened on your particular server. See Wiz’s analysis.

Do not begin by running pip in a suspected environment. The maintainer warns that starting Python there can execute the malicious startup files again. Even a command intended to inspect the installation may start Python.

How do I find out whether we installed it?

Begin with records you can inspect outside the suspected environment:

• Check build logs and lockfiles for LiteLLM 1.107.0.

• Check when CI jobs or servers installed it.

• For containers, find the image digest that actually ran. A digest identifies a particular image; a moving tag such as latest does not.

• List the services, jobs and machines that used those builds.

• List the credentials those environments could access.

For example, pulling a clean latest image today does not tell you what yesterday’s deployment used. Look at the deployment record and original image digest.

Using LiteLLM does not by itself mean you installed an affected artifact. Establish that from the records before describing a particular system as exposed.

What should an affected team do next?

Bring in the person responsible for security or infrastructure and follow the live maintainer instructions. Preserve relevant logs before cleanup removes evidence.

Track two parts of the recovery:

Rebuild the affected environment. The maintainer recommends treating it as compromised, addressing the startup files and rebuilding where possible. A fresh environment avoids relying on package removal to find every malicious file.

Replace exposed credentials and review their use. Work with the services that issued those credentials. Check for unexpected access, resources or charges. Deploy replacement credentials to the rebuilt application and test that it still works.

A successful application restart only shows that the application starts. It does not show that stolen credentials have stopped working elsewhere.

What changed in the root-cause report?

The 23 October canonical investigation supersedes early theories about tokens being taken from request logs. LiteLLM says a master key exposed in a public repository was not revoked. An attacker used it to access the Agent Platform and retrieve an organization owner’s GitHub token, then obtained additional CI secrets and altered the release workflow.

For teams building agents, the practical lesson is to revoke exposed keys immediately and give automation narrowly scoped credentials. Removing a leaked key from Git history does not revoke it.

What should we change in our release process?

Keep enough information to identify the artifact each deployment used: the package version, build time and container digest where applicable. Pinning versions helps you reproduce a build, but a pinned version can still be malicious.

For this incident, the useful review questions are specific: Did we run an affected artifact? Which environments used it? Which credentials could they reach? Those answers give the recovery team somewhere concrete to begin.

Checked 25 October 2026 against the linked incident report, canonical investigation and Wiz analysis. Consult the live maintainer guidance before recovery. TechWebster has not independently reproduced the malware.