On March 24, 2026, attackers published backdoored versions of LiteLLM to PyPI. The malware harvested cloud credentials, SSH keys, Kubernetes tokens, and pretty much everything else it could find on the host. This is the full breakdown of how it happened, step by step. The Scale of Impact LiteLLM gets roughly 3.4 million downloads per day. The compromised versions (1.82.7 and 1.82.8) were live on PyPI before being detected. Any organization that: Installed litellm for the first time during the window Updated litellm to the latest version during the window Had a CI/CD pipeline that pulled litellm without pinning to a specific version ...should assume that every credential accessible from that environment has been stolen. The remediation guidance is severe: rotate every secret that was present on any machine where the compromised version was installed. SSH keys, cloud credentials, database passwords, API keys, Kubernetes tokens. All of it. What is LiteLLM? LiteLLM is an open-source Python library that acts as a unified proxy for large language models. It lets developers write one API call and route it to OpenAI, Anthropic, Google, Mistral, Cohere, or any other LLM provider without rewriting code for each provider's SDK. It's massively popular. Around 95 million monthly downloads on PyPI. Thousands of companies use it as the backbone of their AI stack because it makes switching between LLM providers trivially easy. You install it with pip install litellm, import it in your Python code, and it handles the rest. That "installed directly into your application runtime" part is important. Keep it in mind. Who is TeamPCP? TeamPCP is the threat actor behind this attack. They're also responsible for compromising Aqua Security's Trivy vulnerability scanner on March 19, 2026 and Checkmarx's KICS GitHub Action on March 23. The LiteLLM attack on March 24 was the third stage of a broader campaign. The Attack Chain, Step by Step This wasn't someone finding a bug in LiteLLM's code. It was a multi-stage supply chain attack that moved laterally across three different open-source projects before reaching LiteLLM's users. Stage 1: Compromising Trivy (March 19) Trivy is a popular open-source vulnerability scanner made by Aqua Security. Millions of developers and CI/CD pipelines use it to scan container images, code repos, and infrastructure for security issues. How it was compromised: TeamPCP found a misconfigured GitHub Actions workflow in Trivy's repository. Specifically, a pull_request_target trigger. Here's why that matters. In GitHub Actions, there are two ways to run workflows on pull requests: pull_request runs the workflow using the code from the pull request itself, but with limited permissions. Safe. pull_request_target runs the workflow using the code from the base branch (the main repo), but it gets triggered by an external pull request. The dangerous part is that it gives the workflow access to the repository's secrets (tokens, credentials, etc.) because it's running "trusted" base branch code. The problem is that if the workflow does anything with the PR's code (checks it out, runs it, uses it as input), an attacker can submit a malicious PR that tricks the workflow into executing attacker-controlled code with full access to the repo's secrets. TeamPCP used an account called "MegaGame10418" to exploit this. They submitted a pull request that triggered the vulnerable workflow, which gave them access to Aqua Security's aqua-bot credentials. These were privileged credentials that could push code to Trivy's repositories. What they did with access: With the stolen credentials, TeamPCP force-pushed malicious commits to 75 out of 77 git tags in two Trivy GitHub repositories. This means when anyone pulled Trivy at almost any version tag, they got the poisoned version. They also published a malicious Trivy binary as version v0.69.4. The malicious Trivy contained Python infostealers designed to harvest environment variables, SSH keys, and cloud tokens from CI runners and local systems. Aqua Security's incomplete response: Aqua Security detected the breach and disclosed it. They rotated credentials. But the rotation was incomplete. Some access paths remained open, which allowed TeamPCP to continue their campaign. Stage 2: Pivoting to LiteLLM (March 24) Here's where it gets really interesting. LiteLLM's CI/CD pipeline used Trivy as part of its build process. This is normal. Lots of projects run security scanners in their pipelines. The problem was how LiteLLM referenced Trivy. LiteLLM did not pin Trivy to a specific, verified version. When LiteLLM's GitHub Actions workflow kicked off a build, it pulled whatever version of Trivy the tag pointed to. Since TeamPCP had rewritten Trivy's tags to point to malicious code, LiteLLM's pipeline pulled the compromised Trivy and ran it. What the compromised Trivy did inside LiteL