The LiteLLM Supply Chain Attack: How a Poisoned Security Scanner Backdoored the AI Ecosystem

The Morning Everything Broke

On March 24, 2026, a developer at FutureSearch installed a Cursor MCP plugin for an AI project. Within minutes, their machine became unresponsive. The culprit wasn't ransomware. It wasn't a zero-day browser exploit. It was a routine pip install command pulling in a dependency they didn't even know existed in their stack. Their machine had triggered a fork bomb buried inside a malicious version of LiteLLM, a Python library used in virtually every serious AI development environment on the planet.

That fork bomb, it turns out, was a bug in the malware. The credential stealer underneath it was working exactly as intended.

This is the LiteLLM supply chain attack, one of the most consequential open-source compromises of 2026, and a masterclass in how attackers use trusted infrastructure to attack the people who trust it most.

What Is a Supply Chain Attack?

Before diving into the specifics, it helps to understand the broader category. A software supply chain attack targets not your systems directly, but the software you depend on. Instead of hacking your front door, the attacker poisons the hardware store that built your lock.

Modern software is almost never written entirely from scratch. Developers rely on thousands of open-source libraries called dependencies that do everything from handling database connections to calling APIs. When you install a Python library with pip install, you're trusting that the code in that package is exactly what the maintainer intended to publish. Supply chain attacks break that trust.

LiteLLM is an open-source Python library and proxy server that provides a single, unified interface to more than 100 large language model APIs such as OpenAI, Anthropic, AWS Bedrock, and Google VertexAI. It's the glue layer of the AI development world. Major frameworks including CrewAI, DSPy, Mem0, Instructor, and Browser-Use all depend on it. With roughly 95 million downloads per month, it sits in 36% of cloud environments globally. It is, in short, exactly the kind of package an attacker dreams of compromising.

LiteLLM Supply chain attack

How the LiteLLM Supply Chain Attack Worked

This attack didn't start with LiteLLM. It started five days earlier, with a security scanner.

Phase 1: Trivy Compromise (March 19, 2026)

Trivy is a widely used open-source vulnerability scanner built by Aqua Security. It's commonly embedded in CI/CD pipelines, including LiteLLM's own GitHub Actions workflow, to automatically scan for vulnerabilities during builds.

The threat actor group TeamPCP (also tracked as PCPcat, Persy_PCP, ShellForce, and DeadCatx3) force-pushed malicious code to the trivy-action GitHub Action repository, rewriting existing Git tags to point to a compromised release (v0.69.4) carrying a credential-harvesting payload.

This is a particularly dangerous technique: developers pin to tag names, not commit hashes, so pointing a tag at malicious code silently swaps out what they've trusted.

When LiteLLM's CI/CD pipeline ran its scheduled build on March 24 and called Trivy from apt without a pinned version, the compromised action executed inside the GitHub Actions runner environment. It exfiltrated the PYPI_PUBLISH token (a secret credential used to publish packages to the Python Package Index) from the runner's environment variables.

Phase 2: Malicious Package Publication (March 24, 2026)

Armed with a valid PyPI publishing token, TeamPCP published two malicious LiteLLM versions in rapid succession:

• v1.82.7: published at 10:39 UTC, containing an obfuscated payload injected into litellm/proxy/proxy_server.py

• v1.82.8: published at 10:52 UTC, escalating the attack with an additional litellm_init.pth file

Neither version had a corresponding Git tag or release on the official LiteLLM GitHub repository. They were uploaded directly to PyPI, bypassing the normal release workflow entirely. PyPI quarantined the packages at approximately 16:00 UTC, leaving a roughly five-hour exposure window during peak developer working hours.

Phase 3: Payload Execution

The malware was structured in three distinct layers:

[Layer 1]: Launcher & Exfiltration

└── Double base64 encoded launcher in proxy_server.py

└── Decodes and executes Layer 2, captures output, encrypts with AES-256-CBC

└── Exfiltrates via HTTP POST to attacker-controlled domains

[Layer 2]: Reconnaissance & Credential Harvesting

└── Collects: hostname, whoami, uname -a, ip addr, ip route

└── Dumps: ALL environment variables (printenv), API keys, tokens, secrets

└── Steals: SSH keys (~/.ssh/id_rsa, id_ed25519, authorized_keys, known_hosts)

└── Exfiltrates: AWS (~/.aws/credentials, IMDS tokens), GCP, Azure credentials

└── Grabs: Kubernetes configs (~/.kube/config), CI/CD secrets, Docker configs

└── Targets: Database passwords, .env files, .gitconfig, cryptocurrency wallets

[Layer 3]: Persistence & Remote Control

└── Installs system level persistence via sysmon-style service

└── Deploys malicious Kubernetes pods named node-setup-{node_name}

└── Establishes reverse shell backdoor for ongoing remote access

└── Contains anti-forensic measures including timestamp manipulation

The .pth Escalation

Python's site module automatically processes .pth files in site-packages/ on every interpreter startup, before any user code runs, without any import statement required. This means that on a system with v1.82.8 installed, every invocation of python, pytest, pip install, or any other Python command triggered the malware.

Exfiltration targets included:

• models[.]litellm[.]cloud (a domain spoofing the legitimate LiteLLM brand)

• checkmarx[.]zone (a domain impersonating the Checkmarx security company)

The Broader TeamPCP Campaign

The LiteLLM compromise was not an isolated incident. It was part of an ongoing, multi ecosystem compromise campaign by TeamPCP that began in December 2025 and progressively escalated in scope and sophistication.

Date	Target	Method
Dec 2025	Initial infrastructure development	Tooling v1 (pcpcat.py) built and tested
Feb 2026	Tooling hardened	v2 with improved stealth and persistence
March 19, 2026	Aqua Security Trivy GitHub Action	Tag hijacking, credential harvesting
March 23, 2026	Checkmarx KICS (npm)	Fake checkmarx-util-1.0.4 package via postinstall hook
March 24, 2026	LiteLLM (PyPI)	Stolen PYPI_PUBLISH token, malicious v1.82.7 and v1.82.8
March 27, 2026	Telnyx PyPI package (v4.87.1 and v4.87.2)	Same infrastructure, C2 at 83[.]142.209[.]203

Verifying Compromise

Check whether your environment was exposed:

• Check for malicious .pth file - find / -name "litellm_init.pth" 2>/dev/null

• Check installed version - pip show litellm | grep Version

• Hunt for malicious Kubernetes pods

• Check for persistence mechanisms

Network IOCs

Domain / IP	Role
models[.]litellm[.]cloud	C2 exfiltration (v1.82.8)
checkmarx[.]zone	C2 exfiltration (v1.82.7, KICS ops)
83[.]142[.]209[.]203	C2 for Telnyx compromise
83[.]142[.]209[.]11	Seed IOC linked to full infrastructure

All three primary domains share the same registrar (Spaceship, Inc.) and hosting provider (DEMENIN B.V.).

File IOCs

Artifact	Description
litellm_init.pth	Malicious .pth persistence file
p.py	Payload script dropped to disk by v1.82.7
tpcp.tar.gz	TeamPCP tool bundle naming convention
Kubernetes pods node-setup-*	Malicious privileged pods for lateral movement
Sonatype advisory Sonatype-2026-001357	Official package vulnerability record

SOC Incident Response Workflow

• Identify exposure: Check all systems and CI/CD runners for litellm v1.82.7 or v1.82.8 installation between March 24, 10:39 and16:00 UTC

• Isolate immediately: Take affected hosts offline or remove from cluster and treat as fully compromised, not merely exposed

• Remove artifacts: Delete litellm_init.pth, p.py, any tpcp.tar.gz bundles, and malicious Kubernetes pods matching node-setup-*

• Rotate all credentials: Every secret that existed in environment variables, cloud credential files, SSH keys, .env files, or Kubernetes secrets on affected systems must be treated as stolen and rotated immediately

• Audit CI/CD pipeline: Review GitHub Actions workflows for Trivy version pinning. Check whether the runner environment was also a source of secrets

• Network forensics: Query firewall and proxy logs for connections to all known C2 infrastructure IOCs listed above, including historical 30-day lookback

• Notify affected parties: If customer or partner credentials were stored on compromised systems, follow your breach notification obligations

The LiteLLM supply chain attack is a precise illustration of where the security industry's assumptions are breaking down. We secured the application layer, so attackers moved to the build pipeline. We hardened the build pipeline, so they poisoned the security scanner watching over it. Every trust boundary that was leaned on - PyPI package integrity, mutable Git tags, CI/CD environment variable security, became a pivot point in a carefully sequenced attack chain.

The AI development ecosystem has grown explosively fast and with a security culture that hasn't kept pace. Packages with tens of millions of monthly downloads are maintained by small teams with minimal secure software development lifecycle controls. Developers build stacks of transitive dependencies they've never audited. CI/CD environments hold keys to production infrastructure with no least-privilege enforcement.

TeamPCP didn't find a novel vulnerability. They just followed the trust graph to its weakest node, and pulled.

Defenders don't need to solve this problem completely. They need to make it expensive enough that attackers move on. Pin your dependencies. Hash your Actions. Scope your secrets. Scan your packages. The tooling exists, the question is whether the AI development community will adopt it before the next supply chain attack.

Happy cyber-exploration! 🚀🔒

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don't forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let's keep the conversation going and make cybersecurity a community effort!

-AJ