95 Million Monthly Downloads Compromised: Inside the LiteLLM Supply Chain Attack

On March 24, 2026, two poisoned versions of LiteLLM — the Python library that routes LLM calls for nearly every major AI agent framework — landed on PyPI. Versions 1.82.7 and 1.82.8 carried a three-stage credential stealer that harvests SSH keys, cloud tokens, Kubernetes secrets, crypto wallets, and more, then encrypts everything with RSA-4096 and ships it to an attacker-controlled domain. No import required. Just installing version 1.82.8 is enough to trigger the payload on every Python process startup.

LiteLLM pulls roughly 95 million downloads per month on PyPI. It has over 40,000 GitHub stars. And for about 13 minutes on March 24 — the gap between the two malicious releases — anyone running pip install litellm without a pinned version got backdoored.

The attack hit Hacker News with 438 points and nearly 200 comments within hours. XDA, Security Boulevard, Endor Labs, and CyberSIXT all published analyses the same day. This wasn’t a niche incident. It was the third confirmed strike by a threat group called TeamPCP in a single week.

What Happened on March 24

The timeline is tight. Version 1.82.7 appeared at 10:39 UTC. Version 1.82.8 followed 13 minutes later at 10:52 UTC. The last clean release, 1.82.6, had been published on March 22.

Neither version has a corresponding tag or release on LiteLLM’s GitHub repository. The packages were pushed directly to PyPI, bypassing the project’s normal release workflow. A commit pushed to one of the LiteLLM maintainer’s forked repositories reads simply: “teampcp owns BerriAI.”

The attack vector: account hijacking. TeamPCP compromised a maintainer’s PyPI credentials — likely using tokens extracted from an earlier attack on Aqua Security’s Trivy vulnerability scanner, which had been used in LiteLLM’s CI/CD pipeline. With publishing access in hand, uploading malicious wheels was trivial.

The two versions use different injection methods. In 1.82.7, 12 lines of malicious code were injected into litellm/proxy/proxy_server.py at line 128, executing at module import time. Version 1.82.8 escalated with a .pth file — litellm_init.pth — that triggers on every Python invocation, regardless of whether LiteLLM is ever imported. The .pth mechanism is a lesser-known Python feature: any .pth file in site-packages with an import statement runs automatically at interpreter startup.

The Three-Stage Payload

This is not a quick-and-dirty smash-and-grab. The malware operates in three coordinated stages.

Stage 1 — Credential Harvesting. The payload systematically sweeps the host for sensitive data across a staggering number of categories:

SSH keys (id_rsa, id_ed25519, id_ecdsa, authorized_keys, config)
Cloud credentials (AWS IMDS metadata, GCP service account tokens, Azure configs)
Kubernetes secrets, service account tokens, and kubeconfig files
Environment variables from .env files across 6+ directories
Database credentials (.pgpass, my.cnf, Redis configs)
Cryptocurrency wallets (Bitcoin, Ethereum, Solana, Cardano directories)
TLS/SSL private keys from /etc/ssl/private/
CI/CD secrets (Terraform state, GitLab CI configs, Jenkins credentials, Drone configs)
Package manager tokens (.npmrc, .vault-token, .netrc)
Shell history files

Stage 2 — Encryption and Exfiltration. Stolen data gets encrypted with AES-256-CBC, wrapped in RSA-4096 OAEP, bundled into a tar archive (tpcp.tar.gz), and POSTed to models.litellm.cloud — a domain designed to look like legitimate LiteLLM infrastructure but controlled entirely by the attackers. The RSA private key stays with TeamPCP, meaning even intercepted traffic can’t be decrypted by defenders.

Stage 3 — Persistence and Lateral Movement. The malware installs a backdoor at ~/.config/sysmon/sysmon.py with a systemd service unit named “System Telemetry Service.” It polls checkmarx.zone/raw every 50 minutes for additional payloads. On Kubernetes clusters, it goes further — deploying privileged Alpine containers named node-setup-{node_name} in the kube-system namespace with full hostPID and hostNetwork access, the host filesystem mounted at /host, and tolerations for all taints including control-plane nodes. This effectively gives TeamPCP root access to every node in the cluster.

TeamPCP’s Month-Long Campaign

LiteLLM is not an isolated incident. TeamPCP has been running a coordinated campaign across multiple software ecosystems throughout March 2026:

February 28: Aqua Security’s Trivy compromised via a GitHub Actions workflow vulnerability
March 19: Trivy re-compromised using residual access, with 44 repositories defaced
March 20: An npm worm deployed across 45+ packages
March 22: Malicious Docker Hub images published
March 23: Checkmarx’s KICS GitHub Action and OpenVSX extensions backdoored
March 24: LiteLLM versions 1.82.7 and 1.82.8 published with the credential stealer

The technical fingerprints are consistent across all attacks: the same C2 domain (checkmarx.zone), same persistence path (~/.config/sysmon/), same service name, same archive naming convention (tpcp.tar.gz), same encryption scheme, and the same oddly specific kill switch that checks for youtube.com connectivity. Each attack compounds the last — credentials stolen from Trivy enabled the KICS compromise, which likely contributed to the LiteLLM takeover.

What makes TeamPCP different from typical supply chain attackers is the velocity and breadth. Five ecosystems — PyPI, npm, Docker Hub, GitHub Actions, VS Code extensions — in under a month. Security researchers at Endor Labs noted that TeamPCP likely maintains a growing “treasure trove” of stolen credentials from each successive attack, enabling an expanding attack surface.

Why LiteLLM’s Compromise Hits Differently

Not all supply chain attacks are equal. LiteLLM occupies a uniquely dangerous position in the software dependency graph because of where it sits: at the intersection of AI agent frameworks and cloud infrastructure.

LiteLLM is a transitive dependency for dozens of major AI projects. DSPy uses it as a primary LLM provider interface. CrewAI falls back to it when vendor-specific libraries aren’t available. Countless MCP servers, LLM orchestration tools, and agent frameworks pull it in automatically. Many developers who were exposed didn’t even know they had LiteLLM installed — it came in through something else.

The discovery itself was accidental. A developer using Cursor IDE noticed an MCP plugin had pulled LiteLLM as a dependency, and the malicious payload spawned an “exponential fork bomb” that exhausted available RAM. Without that visible crash, the credential harvesting would have continued silently.

This highlights a structural problem specific to the AI tooling ecosystem. AI agent frameworks tend to pull in large dependency trees. They run with broad system access — environment variables, cloud credentials, API keys — because that’s what they need to function. And they’re often deployed in environments (development machines, CI/CD pipelines, Kubernetes clusters) where credentials are abundant and monitoring is thin.

Compare this to the Trivy compromise earlier in the month. Trivy is a security scanner — serious, but its deployment footprint is more controlled. LiteLLM sits in developer environments, production backends, and AI pipelines simultaneously. The blast radius is fundamentally wider.

Community Response and What To Do Now

The Hacker News discussion surfaced several important threads. Multiple commenters pointed out that PyPI’s quarantine of the affected versions — while necessary — broke systems using pinned versions of the clean releases. The tradeoff between safety and availability is real, but the consensus leaned toward containment.

Several proposals emerged for systemic fixes: multi-party release authorization for high-download packages, stronger sandboxing during package installation, and reduced dependency counts overall. One developer’s comment resonated: they’d started “getting rid of most dependencies and creating replacements that do just what I need,” predicting a broader shift toward dependency minimalism.

For anyone who installed LiteLLM 1.82.7 or 1.82.8, the remediation path is clear but painful:

Check your version: pip show litellm | grep Version
Search for the malicious file: find $(python -c "import site; print(site.getsitepackages()[0])") -name "litellm_init.pth"
Check for persistence: look for ~/.config/sysmon/sysmon.py and its associated systemd service
Audit Kubernetes clusters for unauthorized pods matching node-setup-* in kube-system
Rotate every credential that was accessible on affected machines — SSH keys, cloud tokens, database passwords, API keys, all of it

The uncomfortable truth: if you ran either compromised version, treat the entire environment as fully compromised. The malware’s encryption scheme means defenders cannot determine exactly what was exfiltrated by analyzing network logs. Assume everything was taken.

The Bigger Question for AI Infrastructure Security

The AI ecosystem has a dependency problem, and it goes beyond LiteLLM. The rush to build agents, tool-use pipelines, and multi-model orchestration layers has created a dependency graph where a single compromised package can cascade across hundreds of projects. LiteLLM is the connective tissue between LLM providers and the applications that use them — and until March 24, almost nobody was thinking about what happens when that tissue turns malicious.

PyPI has no mandatory two-factor authentication for publishers. There’s no requirement for reproducible builds. There’s no multi-signature release process for packages with tens of millions of monthly downloads. These are known gaps, and TeamPCP is systematically exploiting every one of them.

The pattern is clear: attackers are moving up the stack, from infrastructure tools (Trivy) to CI/CD actions (KICS) to application-layer libraries (LiteLLM). Each compromise feeds the next. And in the AI ecosystem, where libraries routinely get broad system access and developers prioritize speed over supply chain hygiene, the attack surface is growing faster than defenses can keep up.

FAQ

Which LiteLLM versions are affected?
Only versions 1.82.7 and 1.82.8 on PyPI are compromised. Version 1.82.6 and earlier are clean. The malicious versions have been removed from PyPI, but anyone who installed them during the window of exposure should treat their systems as compromised.

Do I need to import LiteLLM for the malware to execute?
For version 1.82.8, no — the .pth file triggers automatically on every Python process startup, even if you never import the library. Version 1.82.7 requires an import to activate the payload, as the malicious code was embedded in proxy_server.py.

Who is TeamPCP?
TeamPCP is a threat actor group responsible for multiple supply chain attacks in March 2026, including compromises of Aqua Security’s Trivy, Checkmarx’s KICS GitHub Action, and now LiteLLM. Their signature includes RSA+AES encryption, the tpcp.tar.gz archive format, and the checkmarx.zone C2 domain. Full attribution remains unconfirmed.

How does this compare to other recent supply chain attacks like the XZ Utils backdoor?
The XZ Utils backdoor (2024) was a slow-burn social engineering attack that took years of trust-building. TeamPCP’s approach is the opposite — fast, loud, and cascading, compromising multiple ecosystems in weeks through credential theft rather than long-term infiltration. The LiteLLM attack also specifically targets AI infrastructure, a relatively new attack surface. Both incidents underscore the fragility of open-source supply chains, but the threat models are fundamentally different.

What alternatives to LiteLLM exist for LLM routing?
Options include using provider SDKs directly (OpenAI, Anthropic, Google SDKs), the OpenRouter API for multi-model access, or lighter routing layers like aisuite. Each involves tradeoffs in flexibility and maintenance burden. The LiteLLM incident may accelerate interest in these alternatives, though LiteLLM’s feature set — supporting 100+ LLM providers through a unified interface — remains difficult to fully replicate.

Top AI Product

Leave a comment Cancel reply