On the morning of March 24, 2026, tens of thousands of software developers working on AI applications were unknowingly exposed to malware. The culprit: a poisoned version of a widely used open-source tool called LiteLLM. The damage could have been catastrophic — and the way it was discovered was almost entirely by accident.
First, some context: What is a software supply chain?
When developers build software, they almost never write everything from scratch. Instead, they borrow pre-built components called “packages” or “libraries” — chunks of code that handle common tasks, like connecting to an AI model or managing a database. These packages are downloaded from public repositories, the largest of which for Python developers is called PyPI (the Python Package Index).
The problem is that when you install one package, it often quietly installs several others that it depends on — and those packages install more packages, and so on. This invisible web of dependencies is called the software supply chain. It’s efficient, but it creates a significant vulnerability: if any single link in the chain is compromised, every project that relies on it is potentially at risk.
What is LiteLLM?
LiteLLM is one of the most popular tools in the AI developer ecosystem. Think of it as a universal remote for AI models: rather than writing different code to talk to OpenAI, Anthropic, Google, or Amazon’s AI systems, developers can use LiteLLM as a single, standardized interface. It’s a common fixture in enterprise AI infrastructure, with over 40,000 stars on GitHub and roughly 95 million downloads in the past month.
Because of its role as a connector to AI services, LiteLLM typically sits at the center of a developer’s most sensitive data — API keys, cloud credentials, and access tokens for dozens of services at once.
The attack didn’t start with LiteLLM
This wasn’t an impulsive hack. The attack was traced to a group called TeamPCP, conducting a coordinated multi-week supply chain campaign that had previously compromised other tools.
The chain of events began weeks earlier with Trivy — a popular open-source security scanner that developers use to check their own code for vulnerabilities. The irony is sharp: a tool designed to protect software became the weapon used to attack it. On March 19, the attackers rewrote Git tags in the trivy-action GitHub repository to point to a malicious release carrying a credential-harvesting payload.
Here’s the clever part: rather than uploading a new malicious version of Trivy, the attackers modified existing version tags — injecting malicious code into workflows that organizations were already running. Because many automated build pipelines rely on version tags rather than pinned commits, these pipelines continued executing without any indication that the underlying code had changed.
LiteLLM used Trivy as part of its own automated build and release process. The compromised Trivy action exfiltrated LiteLLM’s PyPI publishing token from its build environment. With that credential, the attackers published litellm versions 1.82.7 and 1.82.8, each containing malicious payloads. Critically, the Trivy compromise had been publicly disclosed five days before the LiteLLM attack — credentials should have been rotated immediately upon that disclosure.
What the malware actually did
Once installed, the malicious LiteLLM package operated in three stages — and it was ruthless.
Stage 1: Steal everything. The malware immediately began harvesting sensitive files from the host machine. The payload was a credential harvester sweeping SSH keys, cloud credentials, Kubernetes secrets, cryptocurrency wallets, and .env files. SSH keys are essentially master passwords for accessing remote servers. Cloud credentials give access to infrastructure on Amazon, Google, or Microsoft’s cloud platforms. .env files are where developers commonly store API keys and passwords in plain text for local use.
Stage 2: Send it to attackers. The stolen data was encrypted and sent to models.litellm.cloud — a domain that had nothing to do with LiteLLM’s actual infrastructure. The use of a convincing fake domain name was deliberate: it was designed to blend in if a developer happened to glance at their network logs.
Stage 3: Dig in and spread. If a Kubernetes service account token was present — Kubernetes being the platform most large companies use to run cloud applications at scale — the malware read all cluster secrets across all namespaces and attempted to create privileged pods on every node, installing a persistent backdoor with a systemd service. In plain terms: it tried to plant itself permanently across the entire cloud infrastructure, not just the one machine it landed on.
Discovery: A crashed laptop saves the day
Callum McMahon at FutureSearch was testing a Cursor MCP plugin that pulled in LiteLLM as a transitive dependency — meaning he never directly installed LiteLLM himself; it came along as a hidden passenger inside another tool he installed.
The malware had a bug. The piece of code designed to run the payload accidentally triggered itself repeatedly, launching an exponential cascade of processes — a “fork bomb” — that consumed all available memory and crashed the machine. McMahon investigated the crash, found the culprit, and reported it to PyPI within hours.
As Andrej Karpathy, one of the most prominent figures in AI research, noted: if the attackers hadn’t made that coding mistake, the malware could have sat undetected for weeks, silently siphoning credentials from developers all over the world.
The cover-up attempt
What happened next revealed the depth of the compromise. When community members began reporting the issue on GitHub, attackers posted 88 bot comments from 73 unique accounts in a 102-second window, flooding the discussion to obscure it. The accounts used were previously compromised developer accounts, not newly created profiles. The original GitHub issue was closed as “not planned” by what appeared to be the LiteLLM account — almost certainly still under attacker control at that point. The developer community opened a parallel tracking thread and took to Hacker News to keep the alarm alive.
The compromised packages were on PyPI for approximately three hours before being quarantined. Three hours doesn’t sound like much — but for a package with millions of daily downloads in a global developer community spanning every time zone, it was more than enough.
The bigger picture: A cascading threat
TeamPCP’s campaign spanned five ecosystems — GitHub Actions, Docker Hub, npm, Open VSX, and PyPI — and security researchers believe the operation is ongoing. Each compromised environment yielded credentials that unlocked the next target.
Because LiteLLM typically sits directly between applications and multiple AI service providers, it often has access to API keys and other sensitive configuration data. Compromising a package in this position allows attackers to intercept and exfiltrate valuable secrets without needing to directly breach upstream systems.
The incident has reignited a debate that developers have long tried to ignore: the software supply chain is a systemic vulnerability, and the AI ecosystem — with its culture of rapidly stacking libraries on top of libraries — may be especially exposed. As Karpathy put it, every package installation is potentially pulling in a poisoned component “anywhere deep inside its entire dependency tree.”
The broader lesson is harder to act on but impossible to ignore: in an era when AI applications are being built at extraordinary speed, often by small teams racing to ship, the software supply chain represents one of the most underappreciated attack surfaces in technology. One compromised link — even a security tool meant to protect you — can hand attackers the keys to everything.