TeamPCP Backdoored LiteLLM on PyPI — 3-Stage Credential Stealer + Kubernetes Backdoor; All Env Vars, SSH Keys, Cloud Credentials Exfiltrated

TeamPCP backdoored LiteLLM 1.82.7 and 1.82.8 on PyPI via a compromised Trivy GitHub Action, harvesting env vars, SSH keys, and cloud credentials and installing a Kubernetes C2 backdoor.

BerriAI LiteLLMCredential exposureSupply chain compromise / Persistent Kubernetes backdoorPyPI LiteLLM package / Kubernetes clusters running LiteLLM / CI/CD pipelines

What happened

TeamPCP hijacked LiteLLM's CI/CD pipeline via a compromised Trivy GitHub Action, stole PyPI credentials, and published backdoored LiteLLM 1.82.7 and 1.82.8. Three-stage malware installed a persistent Kubernetes C2 backdoor and exfiltrated all credentials via AES-256+RSA-4096 encryption.

Why it matters

Any organization running LiteLLM 1.82.7 or 1.82.8 had all credentials in their environment exfiltrated and a persistent Kubernetes backdoor installed on every node. Full lateral compromise across the Kubernetes cluster is achievable post-installation.

Missing authorization check

CI/CD pipeline actions (including security tools like Trivy) should run with minimal scoped permissions and must not hold PyPI publish credentials. Package integrity verification (Sigstore/TUF attestations) on PyPI would have detected or prevented the unauthorized publish.

Would PP block it?

PP limits downstream blast radius: any production action triggered through the compromised proxy still needs a PP receipt from an independent channel. The initial intrusion (supply chain compromise), credential harvest, and Kubernetes backdoor are outside PP's enforcement scope and require pipeline security hygiene — signed packages, scoped CI credentials, pinned GitHub Action versions.

Incident analysis

Timeline and technical read

Timeline

2026-03-24
TeamPCP compromises Trivy GitHub Action in LiteLLM's CI/CD pipeline, stealing PyPI publish credentials.
2026-03-24
Backdoored LiteLLM 1.82.7 published to PyPI. Version 1.82.8 follows with .pth persistence (executes on every Python process startup).
2026-03-24
~2-hour availability window. Credential harvest + C2 backdoor deployed to Kubernetes nodes of affected organizations.
2026-03-24
LiteLLM team detects compromise and publishes clean version. Sonatype, Snyk, Datadog Security Labs, and others confirm the attack.
2026-05-01
TeamPCP identified as same threat actor behind May 2026 GitHub nx-console breach (3,800 repositories).

Technical breakdown

Supply chain entry: compromised Trivy GitHub Action with excessive CI/CD permissions — a common pattern where third-party security-tool Actions accumulate implicit trust over time.
Three-stage attack design: credential harvest → AES-256+RSA-4096 encrypted exfiltration → persistent C2 backdoor. The backdoor survives package removal.
Python .pth persistence (1.82.8) is particularly severe: executes the stealer on every Python process startup, not only when LiteLLM is explicitly imported.
LiteLLM as a target is the highest-leverage point in the AI agent stack: it aggregates all model API keys, routing configs, and credentials for every agent in the deployment.
TeamPCP recurrence (GitHub breach two months later) confirms an organized, persistent campaign specifically targeting AI infrastructure supply chains.

Severity rationale

Critical

Critical: persistent Kubernetes backdoor with lateral compromise capability across every node, plus mass credential exfiltration (all env vars, SSH keys, cloud credentials, database passwords). LiteLLM is the AI proxy in most production agent stacks — compromise of active LiteLLM versions equals full production access. Same threat actor (TeamPCP) as the GitHub nx-console breach two months later, confirming an organized campaign against AI infrastructure.

Team takeaway

The AI proxy layer (LiteLLM and equivalents) is now explicitly targeted by organized supply chain actors. Pin GitHub Actions to commit SHA, scope CI/CD credentials minimally, verify package signatures, and treat any environment that ran LiteLLM 1.82.7 or 1.82.8 as a full infrastructure compromise requiring credential rotation and Kubernetes node audit.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Credential Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at: Downstream action gates (Deploy Gate, Tool-Call Gate) for PP-protected production actions
Still needs: Supply chain integrity, CI/CD credential scope, Kubernetes node compromise, and initial credential exfiltration are outside PP's enforcement scope
Receipt required for: Any consequential action attempted via the compromised proxy: production deployments, data mutations, external API calls originating from LiteLLM-routed agents

PP authority receipts are independent of LiteLLM — a compromised proxy can route model calls but cannot forge PP-signed receipts for high-impact downstream actions. PP does not prevent the supply chain compromise itself, credential exfiltration, or the Kubernetes backdoor.

Related incidents and controls

Critical2026-05-22

GitHub Confirms 3,800 Internal Repos Exfiltrated After Employee Installed Poisoned Nx Console VS Code Extension

Critical2026-06-08

CISA KEV: CVE-2026-42271 in LiteLLM — authenticated command injection via MCP test endpoints, chains to unauthenticated RCE (CVSS 10.0)

High2026-04-22

Bitwarden CLI 'Shai-Hulud' Supply Chain Attack Targeted Claude Code, Cursor, Codex CLI API Keys — 334 Developers Exposed

Credential Gate Why governance must be external

Start small

Put the relevant gate at this action boundary.

This incident maps to Credential Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop