Blog Image

When the Scanner Becomes the Weapon: The LiteLLM Supply Chain Attack Explained

Artificial Intelligence
Read time:7 MinUpdated:March 25, 2026

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.

IF YOU USE LITELLM, READ THIS FIRST

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.

THE SETUP: A TRUST CHAIN, QUIETLY BROKEN

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.

HOW IT HAPPENED: FIVE DAYS, THREE TOOLS, ONE CREDENTIAL

The attack didn't start on March 24. It started five days earlier, and it didn't start with LiteLLM at all.

  1. March 19, 2026: Trivy compromised. TeamPCP rewrote Git tags in the trivy-action GitHub Action repository to point to a malicious release (v0.69.4). Trivy is a popular open-source container and code security scanner. LiteLLM's CI/CD pipeline used it without a pinned version, meaning it automatically pulled whatever "latest" pointed to.
  2. March 23, 2026: Infrastructure staged the exfiltration domain models. litellm.cloud deceptively similar to the legitimate litellm.ai was registered one day before the attack. The same day, a parallel attack hit Checkmarx KICS, another infrastructure scanning tool used in developer pipelines.
  3. March 24, 10:39 UTC: The credential lands, the payload ships LiteLLM's CI/CD runs Trivy as part of its normal build process. The compromised action harvests the PYPI_PUBLISH token from the GitHub Actions runner environment. Within minutes, malicious litellm 1.82.7 appears on PyPI, published with legitimate credentials, indistinguishable from a real release.
  4. March 24, 10:52 UTC: Version 1.82.8 escalates. Thirteen minutes later, a second version ships. This one adds a .pth file that fires on every Python interpreter startup, not just when litellm is imported. The scope just expanded from "litellm users" to "any Python process running on the machine."
  5. March 24, ~13:38 UTC: PyPI quarantine. After community disclosure spread through GitHub, Hacker News (reaching 324 points), Reddit's r/LocalLLaMA and r/Python, PyPI quarantines the package. Window of exposure: approximately 3 hours.

WHAT IT ACTUALLY DID TO YOUR MACHINE

Once executed, the malicious code ran a methodical, three-stage operation.

  • Stage 1: Harvest Everything - The script swept the entire machine for valuable data: SSH private keys, .env files, AWS/GCP/Azure credentials, Kubernetes kubeconfig files and service account tokens, Docker registry credentials, CI/CD secrets (Jenkins, Travis CI, Terraform), shell history, API keys, Slack and Discord webhook tokens, and cryptocurrency wallet seed phrases.
    It also directly queried AWS Secrets Manager and the Instance Metadata Service (IMDS) using a fully implemented IMDSv2 signing routine.
  • Stage 2: Encrypt and Exfiltrate - Collected data was encrypted using AES-256-CBC before transmission. The session key was wrapped with a hardcoded 4096-bit RSA public key, the same key found in the Trivy and KICS payloads, which is the strongest technical attribution link between all three attacks.
    Everything was bundled as tpcp.tar.gz and sent via HTTPS POST to models.litellm.cloud.
  • Stage 3: Stay and Spread -  A backdoor script was dropped at ~/.config/sysmon/sysmon.py with a systemd service disguised as "System Telemetry Service."
    It polls a C2 domain (checkmarx.zone) every 5 minutes for new commands to execute. At the time of analysis, the endpoint was returning YouTube URLs, but the operator can switch to live payloads at will.

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.

WHY YOUR SECURITY TOOLING WOULDN'T HAVE CAUGHT THIS

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.

THE ADVERSARY: TEAMPCP IS A PROFESSIONAL OPERATION

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.

WHAT DOES THIS CHANGE ABOUT AI TOOLING SECURITY

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.

WHAT TO DO RIGHT NOW: YOUR RESPONSE CHECKLIST

  1. Check your installed version: Run pip show litellm | grep Version. If it shows 1.82.7 or 1.82.8, treat the system as compromised. Do not just upgrade.
  2. Pin immediately Run: pip install "litellm<=1.82.6" in all environments and update your requirements files.
  3. Check for the backdoor: Look for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service (described as "System Telemetry Service"). Also check /root/.config/sysmon/ on servers.
  4. Remove persistence artifacts if found: rm -f ~/.config/sysmon/sysmon.py rm -f ~/.config/systemd/user/sysmon.service systemctl --user disable sysmon.service rm -f /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc
  5. Rotate all credentials on affected systems: SSH keys, AWS/GCP/Azure credentials, API keys in .env files, Docker registry credentials (~/.docker/config.json), Kubernetes configs, database passwords, Git credentials, and any cryptocurrency wallet seed phrases.
  6. Audit AWS Secrets Manager and SSM Parameter Store: The payload queries these directly if instance metadata is accessible from the machine.
  7. Check Kubernetes Run: kubectl get pods -A | grep node-setup- If you find pods named node-setup-* in kube-system, assume full cluster compromise and audit all secrets across all namespaces.
  8. Audit your CI/CD pipeline: Pin all GitHub Actions to specific commit SHAs, not version tags. Tags can be rewritten by anyone with repository access. Commit hashes cannot.

THE BOTTOM LINE

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.

ABOUT CODISTE

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.

INDICATORS OF COMPROMISE (reference)

Malicious file hashes:

  • litellm_init.pth (1.82.8): 71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238
  • proxy_server.py (1.82.7): a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b
  • sysmon.py: 6cf223aea68b0e8031ff68251e30b6017a0513fe152e235c26f248ba1e15c92a

Malicious domains:

  • models.litellm.cloud (exfiltration)
  • checkmarx.zone (C2 polling)

Sources: Snyk (snyk.io), FutureSearch, Endor Labs, Wiz Threat Center, The Hacker News

Nishant Bijani
Nishant Bijani
CTO & Co-Founder | Codiste
Nishant is a dynamic individual, passionate about engineering and a keen observer of the latest technology trends. With an innovative mindset and a commitment to staying up-to-date with advancements, he tackles complex challenges and shares valuable insights, making a positive impact in the ever-evolving world of advanced technology.
Relevant blog posts
Choosing an MCP Server Managed Service: What Fintech Leaders Look for
Artificial Intelligence
February 23, 2026

Choosing an MCP Server Managed Service: What Fintech Leaders Look for

Get a Free MCP Server Security Audit: Why Now's the Time for FinTech
Artificial Intelligence
March 16, 2026

Get a Free MCP Server Security Audit: Why Now's the Time for FinTech

AutoGen vs CrewAI: Which AI Agent Framework Powers Your Next Build?
Artificial Intelligence
March 27, 2026

AutoGen vs CrewAI: Which AI Agent Framework Powers Your Next Build?

Talk to Experts About Your Product Idea

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.

Contact Us

Phone