LiteLLM 1.107.0: A Supply Chain Attack and What Developers Should Do

Programmers often install libraries with a single command and trust that the package comes from the project’s authors. A supply chain attack exploits precisely this trust: the attacker doesn’t target you, but rather the tool you’re using. This is exactly what happened in the incident involving the LiteLLM library, a popular gateway for working with artificial intelligence models. The malicious version 1.107.0 made its way into the PyPI repository and Docker images on October 21, 2026.

What happened

According to the project’s announcement, its release process was compromised, and version 1.107.0—containing malicious code—was uploaded to public repositories. According to analysts’ descriptions, the malware steals cloud login credentials, developers’ secrets, and keys to artificial intelligence services, and also allows for the remote execution of tools. According to one description, the malicious code executed every time Python was launched in the affected environment, meaning that simply having the package installed was sufficient for it to run.

Which versions are vulnerable

• On PyPI, only version 1.107.0 was affected, across all seven installation files (wheels). It was available from approximately 11:39 to 13:23 UTC on October 21.
• On Docker, the affected images were labeled v1.107.0, latest, main-latest, and main-stable, which contained the malicious build from approximately 11:46 to 14:20 UTC.
• According to the announcement, the last known safe version is 1.106.2. The official source tag for version 1.107.0 on GitHub does not contain the malicious files, according to the project.

The project removed or replaced packages from PyPI and Docker registries with clean versions and revoked the affected tokens.

How the attacker proceeded

According to the project, the malicious actions were carried out through the GitHub accounts of three engineers, apparently using stolen GitHub CLI OAuth tokens. According to the report, the attacker had access to three sets of login credentials, one of which could trigger workflows (workflows). They disabled branch protection, merged a change that redirected releases to a similarly named repository, triggered a workflow, and signed and published the compromised files.

Where did they get the tokens?

The initial explanation of the project stated that the tokens were likely obtained from internal deployment logs that were accessible via the internet. According to a later analysis dated October 23, the master key for the experimental platform was accidentally published in a public repository on May 27 and was never revoked. According to that analysis, the attacker used it on October 10 to read the organization owner’s token. The investigation is still ongoing, and the details may change.

A Guide to Logos

The project noted that some developer tools insert the GitHub CLI token into the body of the response, and where responses are logged, the tokens may end up in the logs. This is a general warning: logs are sensitive data and should not contain access tokens.

This isn't the first incident

According to reports, this is the second attack on this project’s supply chain in 2026. At the end of March, malicious versions 1.82.7 and 1.82.8 were published on PyPI following the theft of credentials as part of a broader campaign. These two incidents demonstrate that the project and its users are facing repeated pressure.

What to do if you've been using LiteLLM

• Find out what you installed. Verify that on October 21, you downloaded version 1.107.0 from PyPI or a Docker image with one of the listed tags. For images, check which content you actually received.
• If so, consider the environment compromised. Disconnect it from the network, isolate it, and rebuild it from scratch.
• Change all secrets that the malware may have accessed: cloud credentials, AI service keys, GitHub tokens, SSH keys, and environment variables.
• Review the logs for unusual connections and the use of rotated keys.
• Upgrade to the secure version 1.106.2 or a newer, verified version from the project.

For a detailed list of recommended measures and indicators of compromise, please refer directly to the LiteLLM project announcement and the analyses by security firms. We do not provide this list in this article.

How to Protect Yourself from Similar Attacks

• Pin versions and checksums. Do not allow the “latest” version to be installed automatically in production.
• Wait a few days before installing new releases, unless it’s urgent. Malicious versions are usually detected and removed within hours.
• Restrict release permissions. Require independent approval, and do not allow the same login credentials to be used for both approving and deploying a release.
• Use short-lived tokens and revoke those you no longer need.
• Do not expose internal deployments to the public internet without thorough security measures, and do not log secrets.

What we haven't confirmed

• The exact number of affected companies or programmers. We do not have data on the scope.
• The exact cause of the token compromise. Explanations vary, and the investigation is ongoing.
• Impact on Slovakia. Data on Slovak companies is not available.

Conclusion

The LiteLLM incident is yet another reminder that the chain of trust in software development is only as strong as its weakest link: access tokens in logs, an unretrieved key, or overly broad permissions during deployment. If you’ve been using the library, verify the version, replace the secrets, and upgrade to a secure version. If not, take this opportunity to review how your team releases and installs software.