A "pip install" that steals all your credentials: the LiteLLM attack and why your business should care

Callum McMahon was working normally in his code editor when, all of a sudden, his computer ran out of RAM and froze. He wasn’t running anything unusual. He had only updated a plugin. When he investigated the cause of the problem, he discovered something that put the entire developer community on alert: the update had automatically installed a poisoned version of LiteLLM, one of the most popular libraries in the artificial intelligence ecosystem. And that version was carrying a hidden passenger.

The passenger was a credential stealer. Within seconds, the malicious code scanned the system for SSH keys, Amazon Web Services, Google Cloud and Azure credentials, Kubernetes configurations, cryptocurrency wallets, API tokens, database passwords, command histories, and virtually any secret stored on the machine. All of it was encrypted with a 4096-bit RSA key and sent to a server controlled by the attackers.

The most disturbing part: activating the malware didn’t require running LiteLLM or importing the library into any project. Simply installing it was enough. The malicious code ran automatically every time any Python process started in that environment.

But what is LiteLLM and why does it matter?

LiteLLM is a Python library that allows you to connect to over 100 language model providers (OpenAI, Anthropic, Google, among others) through a single interface. It is a key component in the infrastructure of thousands of artificial intelligence applications. It has over 40,000 stars on GitHub and, according to public PyPI data, accumulates approximately 97 million monthly downloads.

But LiteLLM isn’t only installed consciously by developers. It is what’s known as a transitive dependency: many other packages and tools include it as part of their installation. This means you could have LiteLLM on your system without knowing it, because another tool you did install needs it to function. And if that specific version is compromised, your system is too.

Herein lies the cruelest irony of this attack: LiteLLM is, by definition, the package that manages all the API keys for every AI provider in an organization. The attackers chose precisely the component that, by design, has access to all the secrets.

What exactly happened

On March 24, 2026, versions 1.82.7 and 1.82.8 of LiteLLM were published on PyPI (the central Python package repository) with malicious code injected. Neither of these versions corresponded to a legitimate release from the development team: they were uploaded directly by the attackers using stolen credentials.

The attack was progressive. Version 1.82.7 contained the malicious code hidden in a proxy server file, which required the library to be imported in order to activate. But version 1.82.8, published shortly after, was significantly more aggressive: it included a .pth file that runs automatically with every Python process, without needing to import anything. In other words, simply having the library installed was enough to compromise the system.

The malware operated in three phases. First, a credential harvester swept the system looking for SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and configuration files. Second, if it detected that the system was part of a Kubernetes cluster, it deployed privileged pods on every node to extend the compromise across the entire infrastructure. And third, it installed a persistent backdoor that periodically contacted an external server to receive new instructions.

All stolen information was encrypted and sent to models.litellm.cloud, a domain designed to look legitimate but entirely controlled by the attackers.

Who is behind it: TeamPCP and a chain reaction campaign

The attack on LiteLLM was not an isolated incident. It is part of a coordinated campaign attributed to a group known as TeamPCP, which in recent weeks has compromised multiple security and software development tools in what could be described as a domino effect.

The sequence went as follows. On March 19, TeamPCP compromised Trivy, Aqua Security’s vulnerability scanner, injecting malware into its GitHub Actions and Docker Hub images. On March 23, using credentials obtained from the previous attack, they compromised KICS, Checkmarx’s security analysis tool, along with Visual Studio Code extensions and more than 66 npm packages. And on March 24, the attack reached LiteLLM, likely because the project used Trivy in its continuous integration process.

Each compromise generates new stolen credentials that open the door to the next target.

The most concerning aspect of TeamPCP’s pattern is their choice of targets. They don’t attack just any software: they attack the very tools that companies use to protect themselves. Vulnerability scanners, CI/CD actions, API gateways. Tools that organizations implicitly trust and that, by their nature, have privileged access to credentials and infrastructure.

Why this affects your business (even if you’re not a developer)

It’s tempting to read this news and think it’s a problem exclusive to programmers. But the reality is very different. The software that businesses use every day (productivity tools, SaaS platforms, cloud service integrations, internal applications) is built on thousands of dependencies like LiteLLM. And when one of those pieces is compromised, the impact extends across the entire chain.

Let’s consider a concrete scenario. A technology consultancy in Madrid uses an internal AI tool to process client documents. That tool, without anyone explicitly knowing, depends on LiteLLM to connect to language models. If a developer on the team updated dependencies on the morning of March 24, the poisoned version could have been installed automatically. And at that moment, all system credentials would have been exfiltrated.

This is not a theoretical problem. According to researchers at Endor Labs, the malware deployed by TeamPCP in LiteLLM is capable of escalating from a single compromised machine to controlling entire Kubernetes clusters, which in practice means complete access to a company’s entire digital infrastructure.

Software supply chain attacks: the new normal

Software supply chain attacks are not new, but their frequency and sophistication are increasing at an alarming rate. The principle is simple yet devastating: instead of directly attacking thousands of companies, the attacker compromises a single tool that all of them use. A single breach multiplies automatically through the dependency network.

In the specific case of the TeamPCP campaign, the scope is especially concerning. In just five days, the attackers compromised five different ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI. The speed of propagation and the ability to pivot from one target to the next demonstrate a level of operational sophistication that should give pause to any company that depends on software to operate.

What your business can do today

Incidents like the LiteLLM attack highlight an uncomfortable reality: the attack surface of any company that uses software extends far beyond its own systems. It includes every library, every dependency, every third-party tool that is part of the digital ecosystem.

The first priority is visibility. Most companies don’t know how many software dependencies they have or which of them represent a risk. An up-to-date inventory of the organization’s digital components is the starting point for any protection strategy.

The second is response capability. The poisoned version of LiteLLM was available for approximately three hours before being detected and removed. Three hours may seem like a short time, but they are enough for a continuous integration system to automatically update dependencies, build a new production image, and deploy it.

And the third is accepting that absolute prevention doesn’t exist. You can pin dependency versions, audit code, implement strict access controls, and still, an attack like TeamPCP’s can find a way in. That’s why it’s essential to have a strategy that combines prevention, detection, response, and risk transfer.

Timeline of the TeamPCP campaign (March 2026)

March 19 — Trivy compromise (Aqua Security). Malware injection into the vulnerability scanner and its GitHub Actions. 75 out of 76 trivy-action tags modified.

March 23 — KICS compromise (Checkmarx). Using credentials stolen in the Trivy attack, the attackers compromise Checkmarx’s GitHub Actions, VS Code extensions, and more than 66 npm packages.

March 24 — LiteLLM compromise. Versions 1.82.7 and 1.82.8, published with malicious code on PyPI, are detected and removed in approximately three hours. The five affected ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI.