480 Million Downloads. Two Poisoned Versions. Your AI Stack Was the Target.

If your organization uses LiteLLM - and there's a good chance it does - then for a brief window on March 24, 2026, installing or updating that package meant handing your cloud credentials, API keys, and infrastructure secrets directly to an attacker.

Two malicious versions of LiteLLM (1.82.7 and 1.82.8) were uploaded to PyPI, Python's official package registry, by the same threat group behind the Trivy supply chain compromise earlier that month. With roughly three million downloads per day, even the two-hour window before detection meant thousands of systems were potentially exposed.

This was not a theoretical risk. The malware stole credentials, installed persistent backdoors, and in Kubernetes environments, spread itself to every node in the cluster.

Let's talk about how it happened and what it means for anyone building on AI today.

What was the LiteLLM attack?

The LiteLLM supply chain attack was a PyPI compromise where malicious versions (1.82.7 and 1.82.8) stole cloud credentials, API keys, and Kubernetes secrets by exploiting a compromised CI/CD pipeline dependency.

The Domino Effect: From Security Scanner to AI Library

The LiteLLM compromise didn't start with LiteLLM. It started with Trivy.

Two weeks earlier, TeamPCP  the threat group behind this campaign, had compromised Trivy, the popular container vulnerability scanner, and published a malicious release (v0.69.4) through all its official channels. 

Here's where LiteLLM enters the picture. Its CI/CD pipeline included a security scanning step ironically, using Trivy. The build script ran a simple apt-get install trivy with no version pinning and no integrity check. So, when the pipeline executed, it pulled the compromised Trivy binary, which silently stole the pipeline's secrets including the PyPI token used to publish LiteLLM releases.

With that token in hand, TeamPCP published two backdoored versions of LiteLLM to PyPI. The attack was live.

Think about what happened here: a security tool was compromised, which led to the compromise of an AI library in a completely different ecosystem. One unverified dependency in a build script connected the two.

What made this possible wasn’t just a compromised dependency. It was the fact that the build pipeline allowed external artifacts to be fetched and executed at build time without verification.

This is a common pattern across modern pipelines, where convenience often outweighs control.

A different approach is to eliminate that uncertainty entirely by building from pre-verified sources in controlled environments, where every dependency is pinned, validated, and reproducible.

What the Malware Actually Did

It was a three-stage operation designed for maximum extraction and long-term access.

The moment you imported the package, a hidden payload activated. It swept your system for SSH keys, cloud provider credentials (AWS, GCP, Azure), Kubernetes secrets, database passwords, Docker tokens, API keys, environment files, and CI/CD configs. Everything it found was encrypted with AES-256 and RSA-4096, meaning even if you intercepted the outbound traffic, you couldn't read what was being stolen, and sent to an attacker-controlled domain, cleverly disguised as models.litellm.cloud.

If it was running inside Kubernetes, things got worse. The malware enumerated all nodes in the cluster and deployed a privileged pod on every single one, mounting the host filesystem and dropping a persistent backdoor via chroot. One compromised package, and your entire cluster was owned.

Then it dug in for the long haul. A Python script disguised as "System Telemetry Service" was installed as a systemd service, polling the attacker's server every 50 minutes for new instructions. Even after you removed the malicious package, the backdoor stayed ready to execute whatever TeamPCP pushed next.

At this point, the entry vector almost doesn’t matter. Once a poisoned artifact is trusted inside a build or runtime environment, the blast radius is defined by how much implicit trust the system allows.

This is why modern supply chain security is shifting left — not just to detect issues earlier, but to prevent unverified components from entering the system in the first place.

Why AI Infrastructure Is Now a Prime Target

This incident isn't just about one package. It signals a broader shift in what attackers are going after.

LiteLLM sits between applications and AI providers. By design, it handles API keys for OpenAI, Anthropic, Google, and dozens of other services. Compromising it gives attackers access not just to one system, but to every AI service that system connects to. It's the master keyring to an organization's AI operations.

As companies pour investment into AI, the tooling around it - model gateways, inference libraries, orchestration frameworks become increasingly valuable to attackers. These tools are trusted, widely deployed, and often run with elevated permissions. They're the new high-value targets.

And the attack pattern that hit LiteLLM  compromise an upstream dependency, steal pipeline credentials, publish poisoned versions works against any package in any ecosystem. The AI stack just happens to be where the richest secrets are right now.

The Fix Was One Line of Code

After the compromise was discovered, the LiteLLM maintainers fixed their pipeline by changing one thing: they pinned Trivy to a specific, verified version instead of always pulling the latest.

That single change from apt-get install trivy to downloading a specific release with a known checksum would have prevented the entire chain of events. The compromised Trivy binary would never have entered the build. The PyPI token would never have been stolen. The malicious LiteLLM versions would never have been published.

One line of code. That's the margin between a secure pipeline and a supply chain catastrophe. 

In practice, consistently enforcing that level of discipline across pipelines is non-trivial. It requires not just policy, but infrastructure designed to ensure that only verified, reproducible components are ever introduced into the build process.

This is the model platforms like CleanStart are built around - removing variability at the foundation rather than trying to manage risk after it enters the system.

Protecting Your Organization

If you ran LiteLLM 1.82.7 or 1.82.8, assume full credential compromise. Rotate every secret that was accessible in that environment cloud credentials, API keys, registry tokens, SSH keys, Kubernetes service accounts, all of it. Check for the persistent backdoor: look for ~/.config/sysmon/sysmon.py and a systemd service called sysmon.service. In Kubernetes, look for rogue pods named node-setup-* in the kube-system namespace.

For everyone else, the takeaway is straightforward: pin your dependencies, verify their integrity, and treat your build pipeline like the production system it is.

Indicators of Compromise (IoCs):

• ~/.config/sysmon/sysmon.py
• sysmon.service
• Suspicious domain: models.litellm.cloud
• Kubernetes pods: node-setup-* in kube-system

This Wasn’t a LiteLLM Problem. It Was a Build Integrity Problem.

The LiteLLM compromise didn’t happen because of a flaw in the application itself. It happened because unverified artifacts were allowed to enter a trusted build pipeline at runtime.

That pattern exists everywhere.

Any system that pulls dependencies dynamically, without version pinning or integrity verification, is exposed to the same class of attack. Today it was an AI library. Tomorrow it could be anything in your stack.

The takeaway isn’t to avoid specific tools. It’s to eliminate uncertainty from how software is built.

That means:

• No unpinned dependencies in build pipelines
• No runtime fetching of critical components
• Verifiable, reproducible builds from known sources

This is exactly the problem CleanStart is designed to solve.

By constructing container images in controlled, hermetic environments with fully verified inputs, CleanStart removes the conditions that make attacks like this possible in the first place.

Because in modern infrastructure, security isn’t just about what you run.

It’s about how it was built.