What happened
A supply-chain attack on LiteLLM, an open source tool for managing AI API calls, exposed terabytes of credentials from roughly 2,500 organizations including Microsoft, Amazon, Cisco, Samsung, and Salesforce. Security firms CloudSEK and Hudson Rock disclosed the breach, which compromised approximately 434,000 CI/CD pipelines during a 40-minute attack window in March 2026.
The attackers poisoned LiteLLM versions 1.82.7 and 1.82.8 on the Python Package Index (PyPI). Anyone who installed those versions had their environment variables, API keys, cloud credentials, and pipeline secrets scraped and exfiltrated. Hudson Rock obtained a 195TB file containing the stolen data.
The attack chain
The LiteLLM compromise was not an isolated incident. It was the downstream result of an earlier supply-chain attack on Trivy, a widely used vulnerability scanner. The same threat group, calling itself TeamPCP, compromised Trivy’s build pipeline and used a stolen automation token to push malicious code. Trivy’s developers rotated the token but failed to fully revoke it for 20 days, giving attackers nearly three weeks to force-push malicious updates to downstream packages.
The campaign hit four packages in total:
- Trivy – vulnerability scanner (initial entry point)
- KICS – infrastructure-as-code scanner
- Telnyx Python SDK – telecom API client
- LiteLLM – AI API proxy (highest-impact target)
All four packages contained malware that accessed host memory, scraped environment variables, and exfiltrated the data through an attacker-controlled channel.
Why LiteLLM was the high-value target
LiteLLM is used by AI engineering teams to proxy and route API calls to large language model providers. It typically runs inside CI/CD pipelines and production infrastructure with access to sensitive credentials: cloud provider keys, database passwords, Kubernetes secrets, Git tokens, and AI provider API keys. By compromising LiteLLM itself, the attackers gained access to the credential stores of every organization running the compromised versions.
The exposed data types included:
- Cloud keys (AWS, Azure, GCP)
- Repository tokens (GitHub, GitLab PATs)
- SSH keys
- Kubernetes secrets and service account tokens
- Package publishing credentials (PyPI, npm)
- Environment variables containing database passwords
- AI provider keys (OpenAI, Anthropic, etc.)
- Specific secrets like Salesforce client secrets and Slack signing secrets
Scale of the exposure
The list of high-confidence affected organizations reads like a Fortune 500 roster: Nvidia, AWS, Samsung, Salesforce, Cisco, Roche, ServiceNow, Siemens, S&P Global, Airbus, John Deere, Regeneron, London Stock Exchange Group, Thomson Reuters, FedEx, MediaTek, Volkswagen, Deloitte, Kroger, Thales, X Corp, Zscaler, Epic Games, Vodafone, HP, Philips, and dozens more.
Hudson Rock noted that many compromised credentials lacked identifiable company markers. Generic CI/CD pipeline configurations meant database passwords and API keys were exposed without any email domain or internal server name to link them back to a specific organization. The actual number of affected organizations is likely higher than the 2,500 identified.
Who is behind it
TeamPCP claimed responsibility. Researchers described the group as “largely made up of teenagers” but technically capable. The attack did not require sophisticated zero-day exploits or custom malware. It relied on credential hygiene failures in open source build pipelines, specifically the failure to fully revoke a compromised automation token.
Kevin Beaumont, an independent security researcher, confirmed the data is legitimate: “It contains a significant volume of sensitive content at orgs. It’s a massive supply chain breach due to poor AI security, not because AI is the threat, but teens can run circles around orgs obsessed with rushing out AI and poor DevOps security.”
What affected organizations need to do
If your organization used LiteLLM versions 1.82.7 or 1.82.8 at any point, assume your credentials are in the stolen dataset. The recommended response:
- Rotate all credentials in CI/CD pipelines immediately. Not just the ones you think were exposed. All of them.
- Audit environments for the compromised versions. Check pip lockfiles, Docker images, and CI runner caches for LiteLLM 1.82.7 or 1.82.8.
- Invalidate and rotate all cloud keys, Kubernetes service account tokens, and Git PATs that were accessible from the LiteLLM environment.
- Check egress logs for unexpected outbound connections during the period the compromised versions were running.
- Review CloudSEK’s exposure database at exposure.cloudsek.com/ai-supply-chain-incident to see if your organization is listed.
The broader problem with AI supply chains
This attack exposes a structural weakness in how organizations adopt AI tooling. LiteLLM, Trivy, KICS, and the Telnyx SDK are all open source packages that development teams install without the same scrutiny applied to commercial software. AI engineering teams in particular tend to move fast, installing packages to prototype LLM integrations without vetting the supply chain.
The attack also demonstrates how a single upstream failure cascades. Trivy’s 20-day token revocation gap gave attackers enough time to compromise four downstream packages, which in turn exposed 2,500 organizations. Alon Gal, Hudson Rock’s CTO, put it plainly: “A window of roughly 40 minutes in which the LiteLLM dependency was hacked led to over 430,000 instances in which millions of secrets were harvested.”
Practical hardening measures
Beyond the immediate credential rotation, organizations should consider:
- Pin package versions in production environments and review updates before upgrading. The compromised LiteLLM versions were live on PyPI for a short window, but automated dependency updates (Dependabot, Renovate) can pull malicious versions within hours.
- Isolate CI/CD credentials using short-lived tokens and OIDC federation instead of long-lived secrets in environment variables.
- Scan dependencies with tools like pip-audit or Safety, but recognize that vulnerability scanners themselves can be compromised (as Trivy was in this case).
- Monitor PyPI advisories and subscribe to security feeds for critical packages in your stack.
Bottom line
A 40-minute window of compromised LiteLLM packages on PyPI led to one of the largest credential exposures in recent history. The attack did not require sophisticated exploits. It exploited poor credential hygiene in open source build pipelines and the tendency of AI engineering teams to move fast. If you ran LiteLLM 1.82.7 or 1.82.8, rotate everything now. If you did not, use this as the prompt to audit how your CI/CD pipelines handle secrets and whether your AI tooling supply chain has the same vulnerability.