Threat-intelligence firm CloudSEK said in a report published August 11, 2026 that it has identified more than 2,500 organizations potentially exposed by the March 2026 supply-chain compromise of LiteLLM, the open-source gateway developers use to route requests across AI models, and reconstructed roughly 434,000 CI/CD pipelines touched by the exposure.
The figures come from a CloudSEK research report built on a victim dataset the company says its threat-intelligence team obtained covering the March campaign. CloudSEK’s dataset carries high-confidence matches tied to corporate domains, repositories, credentials, or infrastructure belonging to organizations including NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales, and London Stock Exchange Group. The firm is explicit about what the matches mean: high confidence describes the strength of evidence linking exposed information to an organization, not proof that the organization was breached or that an attacker used what was taken.
The incident at the center of the research began on March 24, 2026, when a group tracked as TeamPCP published malicious LiteLLM versions 1.82.7 and 1.82.8 to the Python Package Index. The backdoored releases were live for roughly 40 minutes before removal. That window was enough: CI/CD pipelines install dependencies automatically and often run with broad privileges, so a poisoned package propagates through corporate build systems at machine speed without any developer reviewing it.
How One Leaked Token Reached 434,000 Pipelines
LiteLLM was never attacked directly. The chain documented in CloudSEK’s report starts one step upstream, with Trivy, a widely used open-source security scanner. A leaked automation token associated with the scanner was rotated but not fully revoked, leaving a window of about 20 days in which the attackers force-pushed malicious code over the scanner’s published version tags. Because LiteLLM’s own build pipeline installed Trivy unpinned from the system package manager, the compromised scanner flowed straight into the build, and the poisoned build produced and published the malicious 1.82.7 and 1.82.8 releases to PyPI. One un-revoked token, three tools deep.
The payload design made the short window count. Version 1.82.8 dropped a malicious .pth file into the Python environment, and .pth files execute whenever the Python interpreter starts, whether or not LiteLLM is ever imported. That sidesteps install-time script protections entirely. On compromised runners, the credential stealer that the FBI calls SANDCLOCK escalated to root and swept SSH keys, AWS, Google Cloud, and Azure credentials, Kubernetes service-account tokens, environment files, and CI/CD secrets, scraping values from process memory that tooling normally tries to mask. Cloud keys came straight from the instance metadata service, using access the runner already had rather than any exploit. For AI builds specifically, the haul included LLM API keys and gateway configuration: the credentials to an organization’s entire AI stack.
Stolen data was encrypted under a hard-coded key and exfiltrated to a typosquatted domain. Where exfiltration failed, the malware created a public repository inside the victim’s own GitHub account and uploaded the stolen material there as a release asset, meaning some organizations were publishing their own secrets in plain view.
Why the Risk Outlasted the Package
Removing the malicious releases from PyPI did not close the incident. Any credential copied while the poisoned package was active stays valid until the owner rotates or revokes it, and the package’s removal does nothing on its own. The FBI made the same point in a July 2, 2026 FLASH advisory on TeamPCP, warning that organizations hit by the campaign should treat exfiltrated data and credentials as a persistent risk because affiliated actors are likely to weaponize them long after the initial intrusion.
The advisory confirms the campaign’s scope beyond LiteLLM: TeamPCP trojanized Trivy, Checkmarx’s KICS scanner, LiteLLM, and the Telnyx Python SDK, tools embedded in enterprise pipelines, cloud infrastructure, and security workflows, and paired the intrusions with extortion, publishing victim names on a public leak site and threatening to disclose stolen data.
The FBI’s recommended mitigations overlap almost exactly with what the LiteLLM chain exploited: pin GitHub Actions to verified commit hashes rather than floating version tags, rotate every CI/CD secret and publishing token accessible during the exposure window, enforce least-privilege scoping on service accounts and registry tokens, and search GitHub organizations for repositories named tpcp-docs or docs-tpcp, which the malware creates with stolen credentials.
What the Confidence Labels Mean
CloudSEK sorts the organizations in its dataset by strength of evidence. A high-confidence match rests on identifiable corporate domains, repositories, credentials, or infrastructure; a medium-confidence match carries credible but weaker indicators. Neither label is evidence of a successful attack, and the company stresses the dataset is reconstructed exposure: appearing in it means information associated with the organization was identified and should be investigated, not that a breach is confirmed.
Some caution about scale is warranted. The 2,500-organization and 434,000-pipeline figures come from a dataset CloudSEK obtained through its intelligence channels and reconstructed, and the company sells the exposure-monitoring platform, AIVigil, that this research points toward. None of that undercuts the campaign underneath: the LiteLLM compromise, its place in the wider TeamPCP operation, and the credential classes at risk are corroborated by the FBI’s advisory and by the incident record from March.
CloudSEK has published a free exposure checker where organizations can see whether their infrastructure appears in the dataset. Its guidance for any match is to treat every credential the affected process could read as potentially exposed until validated, review access logs across cloud, source-control, registry, and cluster systems, and rotate broadly rather than just the LiteLLM or model-provider key. For organizations that ran the affected versions in March, the rotation decision has a five-month-old clock already running on it.
