LiteLLM Was Hacked Through Its Own Vulnerability Scanner

The irony is surgical. LiteLLM ran Trivy - a vulnerability scanner - in its CI/CD pipeline to improve security. TeamPCP compromised Trivy on March 19. Trivy's compromised GitHub Action exfiltrated LiteLLM's PyPI publishing token from the CI runner's environment. The attackers then uploaded backdoored LiteLLM packages directly to PyPI, bypassing LiteLLM's own build process entirely.

The security tool was the attack vector. The vulnerability scanner was the vulnerability.

We reported on the initial compromise yesterday. This is the forensic follow-up, now that LiteLLM and multiple security firms have published their analyses.

The Attack Chain

The full sequence, reconstructed from LiteLLM's official postmortem, The Hacker News, Wiz, Snyk, GitGuardian, ReversingLabs, and Endor Labs:

March 19 - TeamPCP compromises Aqua Security's GitHub organization. They rewrite Git tags in the trivy-action repository, pointing release tag v0.69.4 to malicious code. The compromised action harvests environment variables and secrets from GitHub Actions runner memory.

Between March 19-24 - LiteLLM's CI/CD pipeline runs. The workflow includes a Trivy scan step using the compromised trivy-action. During execution, the malicious Trivy action exfiltrates PYPI_PUBLISH - the token that authorizes package uploads to PyPI. The token is sent to TeamPCP's infrastructure.

March 24, 10:39 UTC - TeamPCP uses the stolen PyPI token to upload litellm-1.82.7 directly to PyPI. The package contains a credential-stealing payload embedded in proxy/proxy_server.py.

March 24 (hours later) - TeamPCP uploads litellm-1.82.8 with an additional litellm_init.pth file - a more aggressive delivery mechanism that executes on interpreter startup, not just on import.

March 24, 16:00 UTC - The compromised versions are detected and pulled from PyPI. LiteLLM begins incident response.

Trivy (compromised Mar 19)
    ↓ runs in CI/CD
LiteLLM GitHub Actions runner
    ↓ secrets exfiltrated
PYPI_PUBLISH token stolen
    ↓ used to upload directly
PyPI: litellm 1.82.7, 1.82.8 (backdoored)
    ↓ installed by users
97M monthly downloads exposed

The Three-Stage Payload

The backdoored packages contained a more sophisticated payload than initially reported. Endor Labs and Wiz identified three distinct stages:

Stage 1: Credential Harvester

Sweeps the host for SSH keys, AWS/GCP/Azure credentials, Kubernetes secrets, cryptocurrency wallets, .env files, Docker configs, and shell history. Encrypts the harvest with AES-256-CBC, wraps the session key with a hardcoded RSA-4096 public key, and exfiltrates to models.litellm[.]cloud via HTTPS POST.

Stage 2: Kubernetes Lateral Movement

This stage wasn't in our initial report. The payload uses any discovered Kubernetes service account tokens to enumerate cluster nodes and deploy privileged pods that chroot into host filesystems. In a Kubernetes environment, a single compromised pod can pivot to every node in the cluster.

Wiz estimates LiteLLM is present in 36% of all cloud environments they monitor. A significant fraction of those run on Kubernetes.

Stage 3: Persistent Systemd Backdoor

Installs sysmon.service as a systemd user service that polls checkmarx[.]zone/raw every 50 minutes for next-stage binaries. Includes a kill switch: the service aborts if the URL contains youtube[.]com - a crude anti-analysis measure that assumes sandbox environments redirect traffic to YouTube.

The checkmarx.zone domain is a reference to Checkmarx, another security vendor TeamPCP compromised in their March campaign.

The Five Ecosystems

TeamPCP's March 2026 campaign has now touched five package ecosystems:

Ecosystem	Attack Vector	Date
GitHub Actions	Trivy + KICS action tag rewriting	March 19
Docker Hub	Compromised container images	March 19+
npm	Malicious packages via stolen tokens	March 21+
Open VSX	VS Code extension marketplace	March 21+
PyPI	LiteLLM via stolen publishing token	March 24

The Trivy compromise was the root cause for the LiteLLM attack, but TeamPCP has been expanding laterally across ecosystems for the entire week.

LiteLLM's Response

From LiteLLM's official postmortem:

Removed compromised versions 1.82.7 and 1.82.8 from PyPI
Rotated all maintainer credentials and PyPI tokens
Engaged Google Mandiant for forensic analysis
Paused all new releases pending full supply-chain review
Migrating to PyPI Trusted Publisher (removes stored tokens entirely)
Adding mandatory 2FA and branch protections

Critical detail: Users of the official Docker image (ghcr.io/berriai/litellm) were unaffected because the image pins dependencies to specific versions rather than pulling latest from PyPI.

Indicators of Compromise

If you ran any CI/CD pipeline between March 19-24 that used trivy-action, or installed LiteLLM 1.82.7/1.82.8:

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

# Check for the systemd backdoor
ls ~/.config/sysmon/sysmon.py 2>/dev/null

# Check for rogue Kubernetes pods
kubectl get pods --all-namespaces | grep -i "priv\|chroot\|sysmon"

# Check network logs for C2 domains
grep -r "models.litellm.cloud\|checkmarx.zone" /var/log/ 2>/dev/null

Rotate ALL credentials on any affected system - cloud, SSH, API keys, database passwords, K8s tokens
Audit Kubernetes clusters for unauthorized privileged pods
Check systemd services for sysmon.service
Pin LiteLLM to <=1.82.6 or wait for the post-Mandiant clean release
Audit any CI/CD pipeline that ran Trivy between March 19-24

The Lesson

TeamPCP's message on their Telegram channel: "These companies were built to protect your supply chains yet they can't even protect their own."

They're not wrong. Trivy is a vulnerability scanner. Its entire purpose is finding security problems in your software. LiteLLM added Trivy to their pipeline specifically to improve security. The compromised scanner exfiltrated the credentials needed to compromise everything downstream.

The deeper lesson: your security tooling runs with the same permissions as your build pipeline. If you give a GitHub Action access to your PyPI publishing token, and that Action is compromised, the attacker has your publishing token. Trivy didn't need access to PYPI_PUBLISH to scan for vulnerabilities. But GitHub Actions secrets are available to all steps in a workflow by default. The principle of least privilege wasn't applied to the security scanner itself.

A security scanner designed to protect the supply chain became the entry point for a supply chain attack. Trivy's compromised GitHub Action stole LiteLLM's PyPI token. The attackers uploaded a three-stage payload - credential harvester, Kubernetes lateral movement, persistent backdoor - to a package installed in 36% of cloud environments. The attack window was roughly five and a half hours. The blast radius is still being measured. LiteLLM has Mandiant on the case. TeamPCP has moved on to their next target. And somewhere, a CI/CD pipeline is running a security scan right now with permissions it does not need.

Sources: