LiteLLM Supply-Chain Breach Exposes 2,500 Companies and 434,000 CI/CD Pipelines

What happened

For roughly forty minutes in March 2026, one of the most widely installed pieces of AI plumbing was quietly booby-trapped. On August 11, 2026, the threat-intelligence firm CloudSEK published a report describing how two poisoned releases of LiteLLM reached the Python Package Index and, from there, an estimated 2,500-plus companies and about 434,000 continuous-integration pipeline runs. CloudSEK calls it the largest AI supply-chain breach of 2026 so far.

LiteLLM is an open-source Python library and proxy server that gives an application a single, OpenAI-compatible way to talk to more than a hundred model providers. That role is exactly what makes the incident serious. The library rarely holds the secrets itself, but it sits in the build pipelines and runtime environments that do.

The specific bad versions were LiteLLM 1.82.7 and 1.82.8. They were live on PyPI only briefly before removal, and the project shipped a corrected build on March 24, 2026. As with most supply-chain attacks, automation had already done the damage by then.

How the attack worked

The attackers did not break LiteLLM directly. According to CloudSEK, they compromised the release process of Trivy, a popular open-source security scanner, by abusing a leaked automation token that was never revoked. That token stayed usable for about twenty days.

LiteLLM's build pipeline installed Trivy without pinning it to a fixed version. So when malicious code was force-pushed over Trivy's published version tags, it flowed straight into LiteLLM's build system and got baked into the two poisoned releases. A second scanner, Checkmarx KICS, was swept into the same cascade.

The payload was a malicious Python .pth file, which runs automatically the moment the interpreter starts. That detail matters. A .pth file sidesteps the --ignore-scripts flag that teams lean on to block install-time code, so nothing looked like it was executing a script, and it ran anyway. CloudSEK attributes the operation to a financially motivated group it tracks as TeamPCP.

What the malware harvested

Google tracks the payload as SANDCLOCK. Once running, CloudSEK says it escalated to root and swept up almost every credential a modern pipeline exposes: SSH keys, cloud keys for AWS, Google Cloud and Azure pulled from the instance metadata service, Kubernetes and service-account tokens, environment variables, and the LLM API keys and gateway configuration specific to AI workloads.

It went further than a routine secret-grabber. The malware scraped GitHub Actions masked values straight out of running process memory, defeating the masking that is supposed to keep those values out of logs. Harvested data was encrypted with AES-256 under an RSA-4096 key, and in some cases the stolen material was uploaded to public GitHub repositories as release assets, including one named in CloudSEK's report as tpcp-docs/docs-tpcp. The packages were gone from PyPI in minutes. The credentials they leaked were not.

Who is exposed, and the big caveat

The named organizations read like a cross-section of the Global 500. CloudSEK's high-confidence matches include Amazon Web Services, Samsung Electronics, Salesforce, Cisco, Siemens, Volkswagen, FedEx, Deloitte, London Stock Exchange Group, Thomson Reuters, S&P Global, Vodafone, HP, Philips, MediaTek, Zscaler, Epic Games and X Corp, among dozens more. For some it lists specific counts: 3,459 potential secrets tied to X Corp across 1,153 pipeline runs, 1,218 for S&P Global, 327 for Cisco.

Here is the caveat that belongs next to every one of those numbers. CloudSEK is explicit that these are high-confidence exposure matches, not proof that any company was actually breached, that data was stolen, or that the poisoned code ever executed. Exposure means the vulnerable path was present. Each organization still has to check whether the packages were downloaded, cached or run. CloudSEK also sells an AI-security product, AIVigil, which is worth keeping in mind when reading a single vendor's framing of scale.

What defenders should do now

The remediation checklist is unglamorous and urgent. CloudSEK's guidance is to find any use of LiteLLM 1.82.7 or 1.82.8 and the build windows around it, isolate the affected runners and images, and rotate every credential those processes could reach. That covers cloud, repository, registry, Kubernetes, database, SaaS and AI keys, not just the ones a team assumes were touched.

After the fire drill comes the harder work. Rebuild affected environments from clean sources, hunt for unfamiliar repositories and unexpected outbound traffic, and pin both dependencies and GitHub Actions to verified hashes rather than moving tags. The structural fix is to shorten how long any credential lives and to prefer short-lived workload identity over static keys, so a forty-minute window cannot hand out secrets that stay valid for months.

The bigger picture

The FBI had already flagged the danger. Its FLASH advisory FLASH-20260702-01, issued on July 2, 2026, warned that credentials harvested in this campaign are likely to be weaponized long after the initial intrusion, meaning follow-on attacks remain possible even for companies that have since patched.

The pattern is the real story. A brief compromise of a build-time scanner, amplified by unpinned dependencies and automated pipelines, reached deep into the AI infrastructure of thousands of companies before anyone noticed. As of August 13, 2026, no mass exploitation of the stolen credentials has been publicly confirmed, but the FBI's warning is the point: the exposure window closed in minutes while the credentials it leaked can stay useful for a very long time. The uncomfortable lesson for AI teams is that the gateway routing your model calls is now part of your attack surface, and it inherits the security of everything in its build chain.