TeamPCP 通过被污染的 Trivy GitHub Action 在 PyPI 投毒 LiteLLM 1.82.7 和 1.82.8

Back to incident tracker

2026-03-24

CriticalPrimary

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

Not applicable: no agent authorization boundary was crossed in this incident.

Would PP block it?

The compromise ran through package, credential, or vendor infrastructure rather than through an agent tool call, so there is no agent action for an authorization gate to hold.

Incident analysis

Timeline and technical read

Timeline

1. 2026-03-24

   TeamPCP compromises Trivy GitHub Action in LiteLLM's CI/CD pipeline, stealing PyPI publish credentials.

2. 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).

3. 2026-03-24

   ~2-hour availability window. Credential harvest + C2 backdoor deployed to Kubernetes nodes of affected organizations.

4. 2026-03-24

   LiteLLM team detects compromise and publishes clean version. Sonatype, Snyk, Datadog Security Labs, and others confirm the attack.

5. 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.

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

No agent took an action in this incident. Permission Protocol gates what an agent does, so it does not apply where the harm required no agent action.

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