- What: Threat group TeamPCP compromised the GitHub Actions pipeline of Trivy, the popular vulnerability scanner, used that access to steal LiteLLM's PyPI publishing tokens, then shipped malicious LiteLLM versions
1.82.7and1.82.8carrying a three-stage payload hidden in a Python.pthstartup hook. - Impact: A 153 GB archive of 433,909 files — 118,829 attributed CI runner dumps across 2,488 corporate domains including AWS, Samsung, Cisco, Salesforce, ServiceNow, Siemens, Deloitte, and Epic Games. Harvested: cloud IAM keys, Kubernetes tokens, GitHub/GitLab PATs, AI provider API keys, database passwords, and internal JWTs.
- Fix / mitigation: Audit for LiteLLM 1.82.7/1.82.8, assume every secret reachable from those environments is burned, rotate all of it, review CloudTrail and Kubernetes audit logs back to March 24, 2026, hunt for unauthorized
.pthfiles, and put egress filtering on runner networks. - Who's at risk: Anyone who installed the poisoned versions — but also anyone whose dependencies' CI pipelines did. This attack propagated through two layers of trust before reaching its victims.
The largest AI supply chain breach disclosed this year did not start with the AI component at all. It started with the security scanner. TeamPCP compromised the GitHub Actions pipeline of Trivy — a tool teams run precisely because they care about supply chain security — and used the poisoned scanner's legitimate access inside LiteLLM's CI environment to walk away with the project's PyPI publishing credentials. From there, the attackers were indistinguishable from the maintainers.
LiteLLM is one of the most widely deployed pieces of AI infrastructure in existence: an open-source proxy gateway that gives applications a single interface to over a hundred LLM providers. It sits, by design, in the middle of an organization's AI traffic, configured with the API keys for every model provider the business uses. That is exactly what made it worth two hops of effort to poison.
The Attack Chain: Trust as a Transitive Property
With stolen publishing tokens in hand, TeamPCP shipped LiteLLM versions 1.82.7 and 1.82.8 to PyPI. The malicious releases carried a three-stage payload anchored by a .pth file — a Python packaging mechanism that executes code automatically whenever the interpreter starts. No import of the trojaned package required; if the poisoned LiteLLM was installed in the environment, every Python invocation on that machine ran the attacker's loader.
The payload was built for CI/CD runners, and it collected what runners hold:
- Environment variables — where CI systems inject their secrets
.aws/credentials,.kube/config, and cloud IAM keys for AWS, GCP, and Azure- GitHub and GitLab personal access tokens
- Kubernetes service account tokens and deployment JWTs
- API keys for Salesforce, Slack, Azure — and the AI provider keys LiteLLM exists to manage
- Database passwords and internal service credentials
A .pth startup hook runs before your application code, your test suite, or your security tooling ever executes. In an ephemeral CI runner, that means the payload fires, harvests, and exfiltrates inside a machine that will be destroyed minutes later — taking most of the forensic evidence with it. Runner ephemerality, usually a security property, became the attacker's cleanup crew.
The Blast Radius: 2,488 Companies and Counting
The disclosed archive runs to 153 GB — 433,909 files, of which 118,829 are CI runner dumps attributed across 2,488 corporate domains. The named victims read like an index of the global economy: AWS, Samsung, Cisco, Salesforce, ServiceNow, S&P Global, Siemens, John Deere, Deloitte, Epic Games, Orange S.A., TomTom, BT Group.
The more unsettling half of the story is the unattributed remainder. Many dumps contain live credentials but no company email, domain string, or internal hostname — nothing to tell responders whose secrets they are. Those organizations are exposed and have no way to learn it from the data alone. Hudson Rock has stood up a free domain lookup so organizations can check their exposure and claim ethical disclosure of their own material.
If your organization's check comes back clean, that is evidence of absence from the attributed set only. The correct question is not "is my domain in the leak?" but "did any pipeline of ours run LiteLLM 1.82.7 or 1.82.8 after March 24, 2026?" Package inventory answers that; the leak index does not.
What This Breach Says About AI Infrastructure
Three lessons deserve to outlive the incident news cycle.
The AI gateway is a credential concentrator. LiteLLM's job is to hold the keys to every model provider you use and sit in the path of every prompt and response. Any component with that profile — AI gateway, secrets manager, CI orchestrator — deserves pinned versions, hash verification, and its own egress policy, because compromising it once compromises everything it touches.
Security tooling is part of the attack surface. The initial foothold was Trivy's pipeline — a scanner installed to reduce supply chain risk became the vector for the largest AI supply chain breach of the year. Tools with privileged CI access need the same scrutiny as production dependencies, and their release pipelines are now demonstrably a target.
Transitive trust is the real dependency graph. Most affected organizations never made a risky choice. They pinned a popular, well-maintained package whose maintainers' scanner's pipeline was compromised. Your effective trust boundary is the union of every build system in your dependency tree — and no SBOM captures that today.
Immediate Response Steps
- Inventory: search every environment, image, and lockfile for LiteLLM
1.82.7and1.82.8. Check requirements files, poetry/uv locks, container layers, and base images independently — pins hide. - Assume compromise of reachable secrets: if a poisoned version ran, treat every secret that environment could read as burned. Rotate cloud IAM keys, Kubernetes tokens, GitHub/GitLab PATs, AI provider keys, and database credentials — in that order of blast radius.
- Audit backwards to March 24, 2026: review CloudTrail, GCP/Azure activity logs, and Kubernetes API audit logs from the attack window forward for use of exposed credentials.
- Hunt the persistence: inspect
site-packagesfor unauthorized.pthfiles and Linux hosts for unexplained systemd services. - Constrain the future version of this attack: strict egress allowlists on CI runner networks. A runner that can only reach your artifact registry and your VCS cannot exfiltrate a 153 GB archive.
- Check exposure: use the free domain lookup to determine whether your organization appears in the attributed set, and claim your disclosure if so.
Is your CI/CD pipeline watching itself?
RedEye Security helps teams instrument build infrastructure the way attackers see it: as production. Egress baselines for runners, credential-use anomaly detection, and supply chain review for the tools you trust most.
Get an Assessment