LiteLLM Security Incident: What to Do About Version 1.107.0

The LiteLLM security incident began on October 21, 2026, when version 1.107.0 of the Python package was pushed to PyPI and the Docker registry with malware inside. The package steals browser passwords, SSH keys, cloud credentials and provider API keys and sends them out. The last safe version is v1.106.2. Because we are talking about a package downloaded roughly 23 million times a week, the blast radius is wide.

In short:

• v1.107.0 was uploaded to PyPI and Docker with malware; the last safe version is v1.106.2.
• The malicious package stayed live for about 1 hour 44 minutes (between 11:39 and 13:23 UTC).
• The payload steals browser passwords, SSH/GPG keys, cloud credentials and API keys.
• If you ran this version, isolate the environment, rebuild it and rotate all keys.

What is LiteLLM and why does this incident matter?

LiteLLM is a Python package that lets applications connect to different AI model providers through a single interface. According to The Register it is downloaded about 23 million times a week. We could not verify the "92 million per month" figure circulating on social media; the reliable data we have is 23 million per week.

The package usually sits at a point that can reach the API keys of several providers. That is why compromising it puts at risk not just one library but the keys of every service it is connected to.

What happened, and what is the timeline?

According to LiteLLM's official statement, the release pipeline was compromised and v1.107.0 was published with compiled malware. The malicious package stayed live on PyPI between 11:39:51 and 13:23 UTC. Seven wheel files were uploaded in that window.

Docker was affected too. Together with v1.107.0, the latest, main-latest and main-stable tags pointed to the malicious image. According to Wiz's analysis, these images have been removed from Docker Hub and GHCR.

How did the attacker get in?

Actions are said to have been carried out from the GitHub accounts of three engineers using stolen GitHub CLI OAuth tokens. According to The Hacker News, all the tokens involved have been revoked.

This is not the first incident the project has suffered. In the March 2026 incident, versions 1.82.7 and 1.82.8 were affected. That attack was carried out with credentials the TeamPCP group had stolen through Trivy. For the detailed chain, see Snyk's write-up.

What does the malware do?

According to StepSecurity's technical analysis, three files are copied to the root of site-packages during installation: cook.pth, cook.py and sitecustomize.py. These files run every time a Python interpreter starts. In other words, you don't even need to import LiteLLM to trigger the malicious code.

The data it collects includes:

• Browser passwords
• SSH and GPG keys
• Cloud credentials
• Provider API keys stored in the LiteLLM proxy database

The data is encrypted and sent out. A second-stage backdoor daemon also runs. This daemon checks a GitHub dead drop every hour and executes the Python code it finds there. The attacker can keep issuing new commands to the machine even after the initial data has been stolen.

How do I know if I'm affected?

According to the indicators shared by Aikido, look for these files:

• /tmp/.pc_once_*
• /tmp/remote_code_loader.lock

In addition, check the following:

1. Is litellm 1.107.0 in your pip list or lock files?
2. Did your Docker images pull the latest, main-latest or main-stable tags during those hours?
3. Are cook.pth, cook.py or sitecustomize.py present in the root of site-packages?

The malicious version was live for only about 1 hour 44 minutes. Even so, CI/CD pipelines and systems that update automatically may have pulled the package in that window. AISLE reported that it detected the package about 3 minutes after it was published.

What should I do now?

LiteLLM recommends that users pin to v1.106.2 or to a pre-release version. Rescana's guide also highlights the steps of isolating, rebuilding and rotating keys.

If you think you may have been affected, follow this order:

1. Isolate. Cut the affected machine or container off from the network.
2. Rebuild. Wipe the system and set it up from scratch. Just removing the package is not enough; the backdoor daemon may stay in place.
3. Pin the version. Specify litellm==1.106.2, and use a version number or digest instead of latest in image tags.
4. Rotate all credentials. Including provider API keys, cloud access keys, SSH and GPG keys, and passwords saved in the browser.
5. Review the logs. Look for unusual usage of your keys and spikes in billing.

LiteLLM's private enterprise edition was reported as not affected. Still, verify for yourself which version you are running.

What lasting measures protect against supply chain attacks?

This incident shows that dependency management is a security matter. A few habits reduce the risk noticeably:

• Pin versions. Don't use the latest tag or floating version ranges in production.
• Use lock files and hash verification. If an unexpected file shows up, let the installation fail.
• Add a waiting period for new releases. Updating a few days after publication is the cheapest way to dodge short-lived attacks like this one.
• Give keys least privilege. If a provider key is stolen, the damage it can do should be limited.
• Keep keys easy to rotate. If your rotation process is ready, you lose minutes instead of hours when an incident hits.

Our posts on vulnerabilities in software dependencies may also be useful: Node.js security vulnerability and PHP security vulnerability. To scan your code continuously, also take a look at our post on Claude Security.

Frequently asked questions

What is LiteLLM 1.107.0?

LiteLLM 1.107.0 is the version that was uploaded to PyPI and the Docker registry with malware on October 21, 2026. It steals credentials and leaves a backdoor on the machine. The last safe version is v1.106.2.

Which Docker tags were affected?

Besides the v1.107.0 tag, the latest, main-latest and main-stable tags also pointed to the malicious image. These images have been removed from Docker Hub and GHCR. If you pulled these tags on October 21, rebuild the image.

Is simply removing the package enough?

No. The malware leaves files in the root of site-packages and installs a backdoor daemon that runs hourly. You need to isolate the affected environment, set it up from scratch and rotate all credentials.

Which credentials should I rotate?

Rotate everything that was on the machine: provider API keys, cloud credentials, SSH and GPG keys, and passwords saved in the browser. The malware targets all of them.

Conclusion

The LiteLLM incident showed how a popular package can be turned into a weapon within a short window. The malicious version was live for only about two hours, but the impact of the stolen keys may last much longer. Pin your versions, rotate your keys and review your dependency processes. If you want support with dependency security and infrastructure setup in your software projects, the EngerekTech team can help.

Sources