Threat intelligence firm CloudSEK has published the victim data behind what it calls the largest supply chain attack on AI infrastructure this year, naming more than 2,500 organizations whose build systems may have leaked credentials after the compromise of LiteLLM, an open source gateway that applications use to route requests to large language models.
The intrusion itself dates to March 2026, when a group tracked as Team PCP got malicious builds of LiteLLM's Python packages onto PyPI. They were live for roughly 40 minutes. That was enough: CloudSEK's reconstructed exposure dataset counts 434,000 continuous integration and delivery (CI/CD) pipelines that could have pulled the poisoned dependency, at AI companies, model providers, security vendors, SaaS platforms and industrial groups worldwide.
What's affected
The strongest exposure matches in CloudSEK's dataset include NVIDIA, Cisco, Samsung Electronics, Deloitte, S&P Global, Volkswagen, Orange, FedEx, Thales, Siemens, John Deere, London Stock Exchange Group, Zscaler and X Corp. CloudSEK is explicit that "high confidence" describes the strength of the exposure match and not proof that any listed company was successfully compromised, and it asks that the counts be read as potential exposure rather than confirmed theft. The firm has published a free lookup at hxxps://exposure[.]cloudsek[.]com/ai-supply-chain-incident so organizations can check their own entries.
How the attack works
On each compromised build runner the group's stealer, which Google tracks as SANDCLOCK, escalated to root and swept whatever the machine could reach: SSH keys, AWS, GCP and Azure credentials, Kubernetes service account tokens, .env files and CI/CD secrets. Cloud keys came straight from the instance metadata service and Kubernetes tokens from mounted service account paths, using the access each runner already carried rather than any exploit. On AI builds it also took LLM API keys and gateway configuration, which is effectively the key ring to an organization's entire model stack.
Two details make this worse than a routine poisoned package. GitHub Actions masks secret values in logs, so the stealer read them out of process memory (/proc/<pid>/mem) instead. And where exfiltration to the actor's typosquatted domain failed, the malware created a public repository inside the victim's own GitHub account and uploaded the stolen archive there as a release asset, leaving some organizations quietly publishing their own secrets. Everything collected was sealed with AES-256 under a hard coded RSA-4096 key, so intercepted traffic told defenders nothing.
Why it still matters five months on
Pulling a package ends the distribution, not the incident. Stolen credentials stay valid until somebody rotates them, and the FBI made that point in a July 2026 FLASH advisory (FLASH-20260702-01), warning that actors affiliated with the campaign are likely to weaponize the harvested credentials long after the original intrusion. IntelFusions reported in July that TeamPCP had teamed up with the Vect ransomware crew, which gives that credential pile an obvious buyer, and the campaign fits Google's finding that attackers increasingly poison open source packages instead of breaking into vendors.
What you should do
Treat a match on the list as a credential incident, not a dependency bump. Rotate the cloud keys, repository and package publishing tokens, SSH keys, Kubernetes service account tokens and LLM provider keys that were present on affected runners in March, then search cloud and source control logs forward from that window rather than only around it. Look as well for public repositories created in your own GitHub organization that nobody remembers making. The full write-up, including the disclosure methodology and the complete organization list, is in the original report from CloudSEK's threat intelligence team.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.