Compromised LiteLLM and npm: a warning for developers

In October, attackers published tampered versions of LiteLLM on PyPI and of several npm packages that stole passwords and cloud keys on installation. What happened and what development teams should change.

October 2026 showed once again that the risk is not only in your own code, but also in the libraries you download to build it. Within a few weeks, attackers published tampered versions of popular tools that stole credentials as soon as they were installed, a type of attack known as a software supply chain attack.

LiteLLM 1.107.0: two hours were enough

LiteLLM is a widely used Python library for connecting applications to artificial intelligence models. On October 21, between 11:39 and 13:23 UTC, a malicious version 1.107.0 was available on PyPI, and the Docker images tagged v1.107.0, latest, main-latest and main-stable were also affected, in that case until around 14:20 UTC.

The code installed files that run every time Python starts, even if the program never imports LiteLLM: it stole cloud and AI service keys and opened remote access for the attackers. The LiteLLM team believes the attackers obtained GitHub tokens from three developers through the logs of an internal deployment exposed to the internet, and pointed the release process to a repository with an almost identical name (Berri-AI/litellm). The recommended safe version is 1.106.2.

npm and other compromised packages

tensorlake 0.5.144 (October 8, for one hour and 40 minutes): a variant of the Shai-Hulud worm that stole npm, GitHub, AWS, SSH and .env secrets, republished itself into the victim's other packages and could wipe the user's home folder if its GitHub token was revoked. Tensorlake asks users to remove the malicious gh-token-monitor service before rotating tokens; the safe version is 0.5.143.
@subql/common 5.8.3 (October 5): according to StepSecurity, which made the discovery, a modified publishing workflow downloaded a malicious replacement package that ran both on install and on import. The safe version is 5.8.2.
OVHcloud CLI (October 19): the GitHub account of an OVHcloud developer, compromised by a malicious extension on their personal computer, was used to replace the binaries of versions 0.11.0 to 0.15.0 for about 94 minutes. The clean version is 0.16.0.

Why blocking install scripts is no longer enough

Blocking the scripts that run when dependencies are installed helps, but several of these attacks are triggered when the package is imported or when Python starts, and some were published through the project's own trusted publishing processes.

What development teams should do

Pin exact versions and use lockfiles (package-lock.json, poetry.lock, uv.lock).
Wait a few days before adopting a newly released version, unless it is a security patch.
If you installed an affected version, treat the machine as compromised: rotate every credential it could reach and rebuild environments and images from scratch.
Use short-lived, least-privilege tokens in continuous integration, and keep production secrets separate from development ones.
Monitor outbound connections from servers and pipelines: credential theft needs to send the data somewhere.

October 31 update: each project's advisories

We checked this article against the LiteLLM, Tensorlake and OVHcloud advisories, and the report from StepSecurity, which found the @subql/common attack. We corrected the tensorlake date (it was only published on October 8) and the origin of the OVHcloud attack, and added that the malicious tensorlake service must be removed before rotating tokens. On October 23, LiteLLM warned that parts of its first report were inaccurate, so its account of events may change.

How we help you

In our custom software projects we pin dependencies, review every update and keep secrets out of the code. If your team uses LiteLLM or other AI tools, we can also help you review your artificial intelligence integrations.