By ByteBot
On March 24, 2026, the popular LiteLLM Python package was compromised for three hours, exposing 3.4 million daily downloads to credential-stealing malware. This was not a random attack. It was stage two of a sophisticated supply chain operation that began five days earlier with the compromise of Trivy, a widely-used security scanner. TeamPCP threat actors exploited the ultimate irony: compromise the security tool, steal credentials, compromise the target. If you installed LiteLLM on March 24 between 10:39 and 16:00 UTC, your cloud keys, SSH credentials, and secrets may be in the hands of attackers right now.
The Two-Stage Attack: When Security Tools Become Weapons
This was not a simple hack. On March 19, TeamPCP compromised Trivy, Aqua Security’s vulnerability scanner trusted by thousands of CI/CD pipelines. The attackers force-pushed 76 malicious tags to the trivy-action GitHub repository, redirecting trusted version references to compromised code. Their payload? A credential stealer masquerading as a security tool.
For five days, the compromised Trivy installations silently harvested credentials from CI/CD pipelines—including LiteLLM’s PyPI publishing credentials. On March 24, TeamPCP used those stolen credentials to publish two malicious LiteLLM versions (1.82.7 and 1.82.8) directly to PyPI, bypassing all CI/CD security checks. The official GitHub repository remained clean. The attack was invisible until it was too late.
The sophistication is chilling. Most supply chain attacks target packages directly. TeamPCP targeted the security infrastructure first, then leveraged that access to compromise a library downloaded 3.4 million times per day. Security tools are supposed to protect us. In this case, the security tool was the weapon.
The Malware: Credential Theft at Scale
The malicious payload was not amateur work. It targeted AWS, Azure, and GCP credentials, SSH keys, Kubernetes tokens, Docker configurations, database passwords, cryptocurrency wallets, and CI/CD secrets. The malware used Python’s .pth file mechanism to execute on interpreter startup—before any user code runs, before any security checks trigger.
Once running, it collected credentials from standard filesystem locations, encrypted them using a hybrid AES-256 and RSA-4096 scheme (more sophisticated than most malware samples), and exfiltrated them via POST requests to models.litellm.cloud. That domain looked like legitimate LiteLLM infrastructure. It was not.
PyPI quarantined the malicious versions within three hours of discovery, but the damage was done. Anyone who installed LiteLLM during that window—whether via pip install, automated CI/CD deployments, or transitive dependencies through other frameworks—was compromised.
Who Was Affected
If you ran pip install litellm or pip install -U litellm on March 24 between 10:39 and 16:00 UTC, you were affected. If your CI/CD pipeline has unpinned LiteLLM dependencies and deployed during that window, you were affected. If you use an MCP server or framework that depends on LiteLLM and updated dependencies that day, you were affected.
You were NOT affected if you used the official LiteLLM Proxy Docker image, LiteLLM Cloud service, pinned your dependencies to version 1.82.6 or earlier, or installed from the GitHub repository instead of PyPI.
The blast radius is significant. With 3.4 million daily downloads and a three-hour exposure window, tens of thousands of installations are estimated to be compromised. The potential damage includes cloud infrastructure takeovers, exposed Kubernetes clusters, stolen database credentials, and compromised CI/CD pipelines that could enable persistent access.
What Developers Should Do Now
If you were affected, act immediately. The official LiteLLM security advisory provides detailed guidance and scanning scripts:
- Check your pip install history for March 24 between 10:39 and 16:00 UTC.
- Search for
litellm_init.pthin your site-packages directories—its presence confirms compromise. - Rotate ALL credentials: cloud provider keys, SSH keys, API tokens, database passwords, cryptocurrency wallet keys.
- Review cloud account activity logs for unauthorized access or unusual resource creation.
- Check CI/CD logs for unexpected network connections to models.litellm.cloud or other suspicious domains.
Long-term, this incident is a wake-up call for dependency management. Pin your dependencies with exact versions using == in requirements.txt, not >= ranges. Use lockfiles: requirements.txt with hashes, poetry.lock, or Pipfile.lock. Update dependencies intentionally, with testing, not automatically. Version pinning is not about avoiding updates—it is about controlling when they happen.
The Industry Reckoning: Trust Is Broken
The LiteLLM attack is not an isolated incident. It is part of a pattern. Solarwinds compromised build systems. Codecov compromised CI/CD tools. Log4Shell exploited ubiquitous dependencies. Now Trivy and LiteLLM show that even security tools are attack vectors. The supply chain is the weakest link in software security.
PyPI responded quickly with a three-hour quarantine, but the response was reactive, not proactive. There was no automated malware scanning before publish. There were no anomaly detection systems flagging two rapid version publishes from stolen credentials. The package registry trusted the credentials. The credentials were stolen. The system failed.
The Python community is debating what comes next. Should PyPI require two-factor authentication for packages above a certain download threshold? Should there be mandatory security audits for critical packages? Should package registries scan for malicious code before making new versions available? The current trust model—maintainers are trusted, PyPI is trusted, CI/CD is trusted—has been exploited.
TeamPCP is not finished. On March 22, three days after the Trivy compromise, they defaced all 44 internal repositories in Aqua Security’s GitHub organization, renaming them with a “tpcp-docs-” prefix in a two-minute scripted burst. This was not cleanup. It was a message: We own your infrastructure. Expect more.
Supply Chain Security Is Everyone’s Problem
The sophistication of this attack should concern every developer. Five days of patience between compromising Trivy and attacking LiteLLM. Credential harvesting through a trusted security tool. Direct PyPI publishes bypassing CI/CD. Malware designed to look like legitimate infrastructure. This was not opportunistic. It was calculated.
Supply chain attacks are now the primary threat to software security. Every dependency is a trust decision. Your CI/CD pipeline is your attack surface. Even security tools need security. Defense in depth means pinning dependencies, monitoring network activity, auditing what you pull in, and isolating CI/CD credentials. Assume compromise. Plan for detection and recovery.
If you installed LiteLLM on March 24, rotate your credentials now. If you did not, pin your dependencies. The next supply chain attack is already in progress. We just do not know which package yet.
