💻 AppSec

TeamPCP Backdoors LiteLLM on PyPI — AI Gateway Package With 3 Million Daily Downloads Compromised

The LiteLLM Python package — a widely-deployed AI gateway library with three million daily downloads — was backdoored on PyPI on 24 March by threat actor TeamPCP. Malicious versions 1.82.7 and 1.82.8 deployed a three-stage payload stealing cloud credentials, Kubernetes secrets, and CI/CD tokens from any system that installed the package during a 40-minute window.

4 min read
#supply-chain#pypi#litellm#teampcp#credential-theft#kubernetes#ai-security#cicd#backdoor

What Happened

On 24 March 2026, threat actor TeamPCP published two backdoored releases of the litellm Python package to PyPI: versions 1.82.7 and 1.82.8. The malicious versions were live for approximately 40 minutes — from 10:39 UTC — before PyPI quarantined them following security researcher reports.

LiteLLM is an AI gateway library that allows developers to call OpenAI, Anthropic, Mistral, Cohere, Gemini, and over 100 other LLM providers through a unified API. With three million daily downloads and deep integration as a transitive dependency in AI agent frameworks, MCP servers, and LLM orchestration tools, the blast radius from even a 40-minute window is substantial.

Attack Vector: Poisoned CI/CD Security Tool

TeamPCP gained publish access to LiteLLM’s PyPI account through a sophisticated supply chain pivot. The attack chain:

  1. TeamPCP compromised the Trivy security scanner GitHub Action used by LiteLLM’s CI/CD pipeline
  2. The malicious Trivy action executed during a LiteLLM release workflow, capturing the maintainer’s PyPI publish credentials from the pipeline environment
  3. TeamPCP used the stolen credentials to push the backdoored releases

This technique — compromising a security tool to steal secrets from the pipelines that trust it — is particularly insidious because security scanning actions are by definition given access to sensitive pipeline contexts.

The Three-Stage Payload

The malicious versions contained a .pth file (litellm_init.pth) in the package. Python processes this file type automatically on interpreter startup when it is present in a site-packages directory, meaning the malware executes on every Python process start — not just when import litellm is called.

The payload operated in three stages:

Stage 1 — Credential harvesting. The initial payload performed broad exfiltration targeting over 50 categories of secrets including: cloud provider credentials (AWS, Azure, GCP), Kubernetes configuration and service account tokens, Docker credentials, CI/CD tokens (GitHub Actions, GitLab, CircleCI), database connection strings, SSH private keys, shell history, and cryptocurrency wallet files.

Stage 2 — Kubernetes lateral movement. If a Kubernetes configuration was found, a second module attempted to enumerate and compromise the cluster — using stolen service account tokens to create new privileged pods, extract secrets from all namespaces, and establish persistent access.

Stage 3 — Persistent backdoor. A remote access backdoor was installed providing ongoing code execution independent of the LiteLLM package itself.

Collected data was AES-256 encrypted, RSA-4096 wrapped, and exfiltrated to models.litellm.cloud with the header X-Filename: tpcp.tar.gz.

Scope and Impact

Any system that installed litellm==1.82.7 or litellm==1.82.8 between approximately 10:39–11:20 UTC on 24 March 2026 should be treated as fully compromised. This includes:

  • Direct installations via pip install litellm
  • Docker images built during that window that ran pip install litellm without a pinned version
  • Systems that installed any package that lists litellm as a transitive dependency and resolved to the compromised version

Given LiteLLM’s role as a transitive dependency in AI agent frameworks, many organisations may be exposed without knowing they use LiteLLM at all.

  1. Audit package installations: check any Python environment, Docker image, or CI/CD pipeline that ran pip operations on 24 March 2026. If litellm==1.82.7 or 1.82.8 was installed, treat the environment as compromised
  2. Rotate all credentials that were present on affected systems: cloud provider keys, Kubernetes service accounts, database passwords, CI/CD tokens, and SSH keys
  3. Check for persistence: the malware installs a backdoor independent of the litellm package. Removing the package is not sufficient. Rebuild affected containers from clean base images; re-image affected VMs
  4. Upgrade litellm: pin to version 1.82.9 or later, which removes the malicious .pth file
  5. Audit Kubernetes clusters: if any affected system had Kubernetes access, enumerate cluster resources for evidence of new pods, service accounts, or role bindings created around 24 March
  6. Review CI/CD pipeline dependencies: audit all GitHub Actions in use, particularly third-party security scanners, and pin them to specific commit SHAs rather than version tags

TeamPCP Campaign Context

This is not TeamPCP’s first PyPI supply chain attack. Wiz and Datadog researchers note this attack continues an ongoing campaign targeting Python packages with high download counts and cloud/AI infrastructure access patterns. The group specifically targets packages used in CI/CD environments and cloud-native applications, maximising the value of each compromised publisher account.