The 40-Minute Attack That Exposed 2,500+ Companies: Full Timeline of the March 2026 LiteLLM Supply Chain Breach

TeamPCP used the stolen PyPI publishing credentials to push these releases directly to PyPI, bypassing LiteLLM's normal GitHub-based release process . The group also compressed additional malicious activity into that same window, including defacing 15 organization repositories, wiping 182 personal repos, and making 70 private BerriAI (LiteLLM's parent organization) repositories public .

How the Attack Worked: A Cascading Supply-Chain Compromise

The attack is a textbook example of a cascading supply-chain compromise. TeamPCP did not attack LiteLLM directly. Instead, they exploited a chain of trust:

1. First compromise: Trivy – On March 19, TeamPCP gained access to the Trivy GitHub Actions pipeline using a credential that had been rotated but not fully revoked . They published malicious Trivy releases that injected a credential-stealing payload into any CI/CD runner that installed the compromised scanner.
2. Second compromise: LiteLLM – LiteLLM's own CI/CD pipeline automatically installed the Trivy vulnerability scanner as a security step. When the pipeline ran on March 24, it pulled the poisoned Trivy version. The malicious payload inside Trivy scraped the CI runner's environment, extracting LiteLLM's PyPI publishing tokens and GitHub credentials .
3. Third compromise: PyPI users – Armed with LiteLLM's PyPI credentials, TeamPCP pushed malicious LiteLLM releases to PyPI. Any developer or organization that ran

   pip install litellm==1.82.7

   or 1.82.8 — or whose CI/CD pipeline automatically pulled the latest version — would have their build environment scraped of secrets.

As CloudSEK noted, "the attack originated from the Trivy dependency used in [LiteLLM's] CI/CD security scanning workflow" . There is no CVE for the LiteLLM compromise itself because nothing in LiteLLM's own code was vulnerable; the vulnerability was in the trust relationship between LiteLLM's build pipeline and its security scanning tool .

Scale of the Data Exfiltration

The full scale of the data theft only became clear five months later when multiple threat-intelligence firms published their analyses:

• Hudson Rock independently obtained and analyzed the attackers' raw exfiltration archive: a 153 GB RAR file containing exactly 433,909 files and 118,829 CI runner dumps, attributed to 2,488 corporate domains .
• CloudSEK reconstructed approximately 434,000 captured CI/CD pipeline files and identified over 2,500 potentially exposed organizations . CloudSEK described the incident as the largest supply-chain attack targeting AI infrastructure identified so far in 2026 .
• The compromised data included cloud platform credentials (AWS, GCP, Azure), AI provider API keys (OpenAI, Anthropic, Cohere, etc.), SSH private keys, Kubernetes service account tokens, Docker registry logins, .env files, database connection strings, Slack signing secrets, Salesforce client secrets, and Git credentials .

The FBI issued a flash advisory on July 2, 2026 (FLASH-20260702-01) warning that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows .

Affected Organizations

The exposed domains included major enterprises across technology, finance, industrial, and telecom sectors. Confirmed named organizations from multiple sources include :

• Technology: Amazon (AWS), Microsoft, NVIDIA, Cisco Systems, Samsung Electronics, Salesforce, ServiceNow, X Corp (formerly Twitter), Zscaler, Roku, Epic Games
• Industrial: Volkswagen, Siemens, FedEx
• Financial: S&P Global, Deloitte
• Telecom: BT Group, Vodafone

CloudSEK's dataset contained "high-confidence matches" tied to corporate domains, repositories, credentials, or infrastructure belonging to these organizations . Hudson Rock noted the archive contained credentials "still valid" for many of these organizations months after the incident .

Kevin Beaumont's Post-Incident Testing

Five months after the breach, independent security researcher Kevin Beaumont conducted a crucial reality check. After the Ars Technica report on the breach, Beaumont tested compromised credentials from a major US technology company that publicly claimed it had "rotated everything." Using a responsible-disclosure policy, he tested the credentials and found that "almost every one worked" — meaning the organization had not actually rotated its compromised secrets despite claiming otherwise .

This finding underscores a critical lesson: statements about credential rotation and actual credential rotation are often two different things, and the stolen credentials from this attack remain a live threat.

Urgent Recommendation

Treat all secrets, API keys, cloud credentials, SSH keys, Kubernetes configurations, and any other sensitive data that were accessible to LiteLLM versions 1.82.7 or 1.82.8 as fully compromised. Immediate rotation of every credential that could have been exposed during the March 24, 2026 window is essential — regardless of whether an organization believes it has rotated them already .

The attack is considered the largest AI infrastructure supply-chain breach of 2026, and the stolen data remains a persistent threat for follow-on intrusions, as demonstrated by Beaumont's credential testing . The FBI has warned that follow-on targeting is likely, and the treasure trove of valid credentials in the 153GB archive is a gift that keeps on giving for threat actors.

If your organization used LiteLLM in any capacity on March 24, 2026, assume compromise. Check for the malicious .pth file (litellm_init.pth) and the persistence backdoor (~/.config/sysmon/sysmon.py), verify the installed version with

pip show litellm