TeamPCP Poisons LiteLLM Package With Three-Stage Backdoor

The threat actor behind recent supply chain compromises of Trivy and Checkmarx GitHub Actions has struck again—this time backdooring LiteLLM, a Python package with roughly 3 million daily downloads used to interface with large language models.

On March 24, 2026, attackers published malicious versions 1.82.7 and 1.82.8 of the litellm package to PyPI. The trojanized versions contained a three-stage payload designed to steal credentials, move laterally through Kubernetes clusters, and establish persistent backdoor access.

How TeamPCP Got In

According to analysis from Wiz and Sonatype, TeamPCP obtained the maintainer's PyPI credentials through their earlier compromise of Trivy, the open-source security scanner used in LiteLLM's CI/CD pipeline. This represents a chained attack—the initial Trivy breach we reported on last week created the access vector for this follow-on compromise.

The malicious versions were live for approximately two to three hours before PyPI quarantined the package. During that window, the package's massive download volume meant significant exposure.

The Three-Stage Payload

The attack employed different delivery mechanisms depending on the version:

Version 1.82.7 embedded base64-encoded malicious code directly inside litellm/proxy/proxy_server.py. The payload executes whenever anything imports litellm.proxy—the standard import path for LiteLLM's proxy server mode.

Version 1.82.8 used a more aggressive approach, adding a .pth file (litellm_init.pth) to site-packages. The .pth mechanism fires on every Python interpreter startup, including when pip, python -c, or an IDE's language server launches Python. No explicit import required.

Both versions deployed the same three-stage attack chain:

Stage 1: Credential Harvesting

The first stage sweeps the compromised system for anything valuable:

• SSH keys and configurations
• Git credentials
• AWS, GCP, and Azure cloud credentials
• Kubernetes config files and service account tokens
• Terraform and Helm configurations
• CI/CD pipeline secrets
• API keys and webhook URLs
• Cryptocurrency wallet data

Collected data gets encrypted using AES-256-CBC with randomly generated session keys, then encrypted again with a hardcoded RSA public key. The encrypted payload is packaged into tpcp.tar.gz archives for exfiltration.

Stage 2: Kubernetes Lateral Movement

If the malware detects a Kubernetes environment, it deploys privileged pods across every node in the cluster to extract secrets and expand access. This mirrors the CanisterWorm behavior we covered earlier, though without the destructive wiper component.

Stage 3: Persistent Backdoor

A Python script (sysmon.py) gets deployed as a system service, polling a remote endpoint every 50 minutes for additional payloads. The backdoor includes sandbox evasion logic—returning YouTube links when it detects analysis environments.

Indicators of Compromise

Malicious files:

• litellm_init.pth (v1.82.8)
• Modified proxy_server.py (v1.82.7 and v1.82.8)

Network infrastructure:

• models[.]litellm[.]cloud
• checkmarx[.]zone

System artifacts:

• tpcp.tar.gz archive files
• /tmp/pglog and /tmp/.pg_state temporary files
• sysmon.py service persistence

Marker variable: Search your codebase for lzcdrtfxyqiplpd—a hardcoded string that indicates GlassWorm/TeamPCP infection.

Attribution and Context

TeamPCP (also tracked as PCPcat, Persy_PCP, ShellForce, and DeadCatx3) has been active since at least December 2025. Some researchers have speculated about possible connections to LAPSUS$, though attribution remains uncertain.

This latest attack continues TeamPCP's pattern of targeting developer infrastructure. The group has compromised GitHub Actions and launched wiper attacks against cloud infrastructure in recent weeks. Organizations using any Python packages should audit their dependencies against the growing list of TeamPCP-associated supply chain compromises.

What To Do

If you installed litellm between March 24-25, 2026:

1. Check your version - Run pip show litellm to see what's installed
2. Treat the system as compromised - Package removal alone isn't sufficient due to persistence mechanisms
3. Rotate all credentials - SSH keys, cloud credentials, Kubernetes secrets, API tokens, everything
4. Hunt for IOCs - Search for the marker variable, .pth files, and network indicators
5. Consider full rebuild - Forensically investigate, then rebuild from a known-clean state

The two-hour exposure window and 3 million daily download volume means this compromise likely affected a substantial number of organizations. Those running LiteLLM in production—especially in Kubernetes environments—should prioritize incident response.