

A security tool built to protect your code was hijacked to steal your secrets. Here's how a single compromised GitHub Action led to 3.4 million daily LiteLLM users being exposed and what it means for everyone building with AI.
Run this command right now: pip show litellm | grep Version
If the output shows 1.82.7 or 1.82.8, treat your system as compromised. Do not just upgrade the malicious payload, which may have already run. Scroll to "What To Do Right Now" for the full response checklist.
On the morning of March 24, 2026, a developer at FutureSearch sat down to test a Cursor MCP plugin. Minutes later, his machine was nearly unresponsive, with RAM completely exhausted. He traced the culprit to a freshly installed Python package: litellm, one of the most widely used AI model routing libraries in the world, downloaded roughly 3.4 million times per day.
What he found inside that package was not a bug. It was a fully engineered, three-stage attack. And the path it took to get there through a security scanner, a CI/CD pipeline, and a set of stolen credentials is exactly the kind of attack that most security checklists are completely blind to.
The attacker didn't hack LiteLLM directly. They used LiteLLM's own security tooling against it.
This is the story of how a threat actor known as TeamPCP turned a routine CI/CD security scan into the master key for one of AI infrastructure's most critical libraries.
The attack didn't start on March 24. It started five days earlier, and it didn't start with LiteLLM at all.
Once executed, the malicious code ran a methodical, three-stage operation.
The Kubernetes angle is the most dangerous part for teams running LiteLLM as an LLM gateway: if a Kubernetes service account token exists at the standard mount path, the payload reads secrets across every namespace and attempts to deploy a privileged pod named node-setup-{nodename} to every node in the cluster, mounting the host filesystem and installing the backdoor on the underlying machine. This is a full cluster compromise scenario.
Here's what makes this incident genuinely alarming: it passed every standard integrity check.
The litellm_init.pth file in 1.82.8 is correctly declared in the wheel's RECORD file with a matching hash. Running pip install --require-hashes would have passed cleanly. There is no hash mismatch, no typosquatted package name, no suspicious domain embedded in the source because the package was published using the real maintainer's real credentials.
Hash verification confirms a file matches what PyPI advertised. It cannot tell you whether what PyPI advertised is malicious.
The .pth mechanism, a CPython feature that executes code on every interpreter startup, has been flagged as a security risk in CPython's own issue tracker since 2023 (issue #113659). No patch has been applied. This means the 1.82.8 payload fires when you run pip, when your IDE starts its language server, when a CI/CD step boots a Python process, not just when you import litellm.
The only real detection path at install time is inspecting whether a package drops .pth files containing patterns like subprocess, base64, or exec. No widely deployed pip plugin does this automatically today.
This wasn't an opportunistic attack. TeamPCP (also tracked as PCPcat, Persy_PCP, ShellForge, DeadCatx3) has been active since at least December 2025 and is running a coordinated, numbered campaign. The LiteLLM compromise was Phase 09.
The consistent RSA public key across Trivy, KICS, and LiteLLM operations is the clearest attribution signal: the same infrastructure, the same key pair, the same tpcp.tar.gz bundle naming across three separate supply chain attacks over five days.
Two details from this campaign stand out as genuinely new in the threat landscape:
First, TeamPCP has deployed a component called CanisterWorm that uses Internet Computer Protocol (ICP) blockchain canisters as a command-and-control channel that cannot be taken down by domain registrars or hosting providers. Aikido Security documented this as the first observed use of ICP as a C2 mechanism in a supply chain campaign.
Second, a component called hackerbot-claw uses an AI agent (openclaw) for automated attack targeting one of the first confirmed cases of an AI agent operating autonomously within a supply chain attack campaign.
The issue suppression demonstrated the same professionalism: 88 bot comments from 73 previously compromised developer accounts (not purpose-made fake profiles) flooded the GitHub disclosure issue in a 102-second window. The compromised maintainer account then closed the issue as "not planned." The community opened a parallel tracking issue and continued on Hacker News.
On their Telegram channel, TeamPCP was direct: "These companies were built to protect your supply chains, yet they can't even protect their own... we are already partnering with other teams to perpetuate the chaos, many of your favourite security tools and open-source projects will be targeted in the months to come."
This is not the end of this campaign.
The target selection across this campaign is deliberate and instructive. TeamPCP didn't go after a random Python library. They went after tools with the highest credential density, the ones that, by design, need to read everything to do their job.
Trivy: a security scanner that runs in CI/CD with broad read access to your build environment. KICS: an infrastructure-as-code scanner with visibility into your cloud configs. LiteLLM: an LLM gateway that, in its most common deployment pattern, holds API keys for every model provider your team uses.
For organizations running LiteLLM as a centralized LLM proxy, increasingly the default architecture for teams managing multi-provider AI access, a single compromised host doesn't just expose that host. It potentially exposes every API key for every model provider the gateway was authorized to reach.
The disclosure spreading through r/LocalLLaMA and Hacker News rather than through CVE feeds reflects a broader reality: the AI developer community moves fast, builds on fast-moving dependencies, and relies on community discovery rather than formal security processes. Adversaries are actively exploiting that gap.
AI infrastructure is maturing fast. Its security posture is not keeping pace. The tools we use to build with LLMs are now high-value targets and most teams aren't treating them that way yet.
The LiteLLM incident is a preview of a threat category that will only grow. As AI tooling moves from experiment to enterprise infrastructure, the libraries, gateways, and orchestration tools at the center of LLM deployments become increasingly attractive targets not just for the code they run, but for the credentials they hold.
The Trivy → LiteLLM attack chain should be a wake-up call for every team that has adopted AI tooling with the same velocity they adopted the models themselves. Unpinned CI/CD dependencies. Broad credential access. Fast-moving package ecosystems with thin security review. These aren't new problems, but the stakes are higher now that compromising one gateway can expose every model provider a team is connected to.
The answer isn't to slow down AI adoption. It's to build with the same security rigour you'd apply to any critical infrastructure because that's what this has become.
At Codiste, we build AI systems for teams that can't afford to be the next incident report. From secure LLM gateway architectures to supply-chain-aware CI/CD pipelines, we bring engineering depth and security-first thinking to every AI deployment we work on. If this incident prompted you to review your AI infrastructure, or if you're building from scratch and want to get it right, we'd like to talk. Visit codiste.
Malicious file hashes:
Malicious domains:
Sources: Snyk (snyk.io), FutureSearch, Endor Labs, Wiz Threat Center, The Hacker News




Every great partnership begins with a conversation. Whether you’re exploring possibilities or ready to scale, our team of specialists will help you navigate the journey.