Five months later, the LiteLLM supply chain attack hit 2,500 organizations
In March 2026, TeamPCP backdoored two versions of the LiteLLM Python package on PyPI. The packages were live for about three hours before PyPI quarantined them. At the time, the incident was covered as a moderate supply chain event affecting developers who ran LiteLLM in CI pipelines.
CloudSEK published a scope assessment this week. More than 2,500 organizations were affected. Over 430,000 CI/CD pipelines were exposed.
How it happened
The attack was indirect. TeamPCP did not compromise LiteLLM directly. They first compromised Aqua Security's Trivy open-source vulnerability scanner, which many CI pipelines install automatically as part of their security toolchain. LiteLLM's CI pipeline consumed Trivy automatically. When it did, the compromised Trivy build harvested the LiteLLM maintainer's PyPI credentials and passed them to TeamPCP, who then published the backdoored packages 1.82.7 and 1.82.8.
Snyk published the full attack chain reconstruction. The payload ran in three stages: first it harvested SSH keys, cloud credentials, Kubernetes service account tokens, crypto wallet keys, and .env files from the host; then it attempted lateral movement by deploying privileged pods to every node in any attached Kubernetes cluster; finally it installed a persistent systemd backdoor that polled a TeamPCP-controlled domain for additional binaries.
The scope
2,500 or more organizations exposed their CI/CD pipelines to this payload. A European Commission AWS account was separately assessed as compromised through the same Trivy attack chain, with 91.7 GB of compressed data exfiltrated. Checkmarx confirmed unauthorized access to its GitHub repositories through the Trivy compromise.
The three-hour window during which the malicious packages were available was enough because many CI pipelines install the latest version automatically without pinning. Any pipeline that ran a LiteLLM install between the publication of 1.82.7 and PyPI's quarantine action was exposed.
What organizations should do now
- Check your pipeline history: determine whether you ran LiteLLM 1.82.7 or 1.82.8. These versions are confirmed malicious. If you did, assume full credential exfiltration from that runner.
- Rotate everything on exposed runners: SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes service account tokens, and any .env values present on the host at the time of the build.
- Audit your Kubernetes clusters for unexpected privileged pods deployed from your CI namespace.
- Review systemd unit files on affected runners for persistent backdoors polling external domains.
- Pin your dependency versions explicitly in all future builds. Do not install the latest version of any security tooling in production CI without a pinned hash. Audit the CI pipelines of the tools your CI pipeline depends on, not just your own.
The meta-lesson
This attack worked because CI pipelines are trusted, automated, and opaque. They run with elevated cloud credentials, often in production contexts, and nobody reads every build log. The attacker did not need to trick a human. They needed to trick an automated process that trusted a dependency that trusted another dependency.
Supply chain security cannot be limited to your direct dependencies. The tools you use to secure your builds are part of your attack surface.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your team is auditing supply chain exposure from this or similar incidents.