On March 24, 2026, versions 1.82.7 and 1.82.8 of the LiteLLM Python package on PyPI were compromised with credential-stealing malware, exposing 95 million monthly downloads to a sophisticated supply-chain attack. The malware uses Python’s .pth auto-execution mechanism to harvest SSH keys, cloud credentials, Kubernetes configs, and crypto wallets without requiring developers to even import the library. This is the third successful attack in five days by TeamPCP, the threat actor who compromised Trivy on March 19 and KICS on March 23.
Auto-Executing Malware: The .pth Technique
The LiteLLM supply chain attack exploits a rarely-used Python feature: .pth files in site-packages directories automatically execute during interpreter startup. The malicious file litellm_init.pth runs on every Python process without requiring import litellm, making it invisible to developers who don’t actively use the package.
This technique is exceptionally dangerous because it operates silently. Standard security scanners don’t flag .pth files as executable code, and the malware triggers on every Python invocation—including CI/CD runners, development environments, and background services. Security researchers at Future Search AI noted the payload initially contained a critical bug: “an exponential fork bomb that crashed the machine” when subprocess spawning re-triggered the same .pth file repeatedly.
Three-Stage Credential Harvester
The malware operates in three stages. Stage one decodes and spawns the orchestrator. Stage two harvests SSH keys, AWS/GCP/Azure credentials, Kubernetes service account tokens, database passwords from environment variables, .git-credentials, shell history, and crypto wallet files. Stage three installs persistence mechanisms: a systemd user service at ~/.config/sysmon/sysmon.py that polls the command-and-control server every 50 minutes, and Kubernetes lateral movement that attempts to create privileged pods on every cluster node.
Stolen credentials are encrypted with AES-256-CBC using a random session key, which is then encrypted with a hardcoded RSA-4096 public key. The encrypted payload is exfiltrated to https://models.litellm.cloud/, an attacker-controlled domain masquerading as legitimate infrastructure.
Third Attack This Week: TeamPCP’s Escalating Campaign
TeamPCP has demonstrated a consistent credential-chaining pattern. The LiteLLM maintainer confirmed: “The compromise originated from our CI/CD pipeline using Trivy for vulnerability scanning. The malicious Trivy version stole our PyPI credentials.” Each breach yields tokens that unlock the next target.
The timeline reveals escalating sophistication: February 28 (Trivy initial compromise), March 19 (Trivy re-compromised with 75/76 GitHub Action tags backdoored), March 20 (45+ npm packages infected), March 23 (KICS and OpenVSX extensions compromised), March 24 (LiteLLM with 95 million monthly downloads). Security researchers at Endor Labs describe this as “a consistent progression where each compromised environment yields credentials for the next target.”
The irony is stark: security scanners are compromising security. Organizations trust vulnerability scanners with broad access to repositories, CI/CD pipelines, and deployment credentials. TeamPCP exploited that trust to propagate across five ecosystems in under a month.
What to Do Right Now
Developers must immediately check for compromised versions. Run pip show litellm and verify you’re not on 1.82.7 or 1.82.8. If you are, uninstall the package and purge package manager caches with pip cache purge or rm -rf ~/.cache/uv. Cached wheels will re-install malicious versions even after PyPI removal.
Check for persistence mechanisms. Look for ~/.config/sysmon/sysmon.py and run systemctl --user list-units | grep sysmon. In Kubernetes environments, audit kube-system for pods matching node-setup-* patterns and review cluster secrets for unauthorized access.
Rotate everything. Assume all credentials present on affected systems are compromised: SSH keys, AWS/GCP/Azure tokens, Kubernetes service accounts, database passwords, and API keys from .env files. The malware also queried cloud metadata endpoints (IMDS) to steal temporary credentials with elevated permissions beyond what’s in credential files.
Supply-Chain Security’s Reckoning
This incident exposes fundamental gaps in package registry security. Despite PyPI’s 2FA requirements and Trusted Publishers adoption reaching 25% of uploads, a single compromised maintainer credential bypassed all controls. The community is now questioning whether single-maintainer control is viable for packages with millions of downloads.
Proposals include mandatory multi-party approval for high-impact packages, SLSA provenance verification, and runtime monitoring for .pth abuse. But these fixes won’t arrive quickly enough to stop TeamPCP’s campaign. Current package registry security is insufficient, and the industry is learning that lesson the hard way.
Key Takeaways
- Check versions immediately:
pip show litellmmust show version other than 1.82.7/1.82.8 - Purge caches: Package manager caches re-install compromised versions even after PyPI removal
- Audit persistence: Check for systemd services and Kubernetes privileged pods
- Rotate credentials: Assume complete compromise of SSH keys, cloud credentials, K8s tokens, and API keys
- Watch for more attacks: TeamPCP’s campaign is ongoing and likely targeting additional packages
