The LiteLLM breach exposed 434,000 CI/CD pipelines, and the weak link was a vulnerability scanner

March 2026. The TeamPCP group compromises LiteLLM, the open source gateway that federates hundreds of LLM providers, by way of the Trivy vulnerability scanner its own pipeline installs. August 11, 2026. CloudSEK publishes the reconstructed exposure count: more than 2,500 organizations and 434,000 CI/CD pipelines worldwide. July 2026. The FBI issues a FLASH advisory warning that the harvested credentials will likely be weaponized long after the initial intrusion.

For a platform team, the conclusion fits in one sentence: a 40-minute publication window on PyPI turned into a months-long incident, because the malicious code ran with no explicit import and the pipelines carried privileges they never should have had.

Three tools deep, one un-revoked token

LiteLLM was never attacked directly. CloudSEK’s account describes a precise cascade: the LiteLLM release process installed the Trivy scanner from the system package manager, without pinning a version. A leaked automation token, rotated but not fully revoked, left a window of roughly 20 days during which the attacker force-pushed malicious code over the scanner’s published version tags.

Builds pulling those tags received a poisoned scanner that still looked legitimate. That compromised scanner flowed into the LiteLLM build, and that build produced and published versions 1.82.7 and 1.82.8 to PyPI. Trivy, then the build system, then the LiteLLM release: one un-revoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure.

The execution vector is the most instructive part. The payload relied on a .pth file, which runs at interpreter startup, not on import. The result: the malicious code ran on any machine where the package was merely installed, even with no import of LiteLLM in the code. It also sidestepped the --ignore-scripts protection many teams rely on to keep installs safe.

What the stealer collected

On every compromised CI runner, the stealer — tracked by Google as SANDCLOCK — escalated to root and swept methodically: SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, .env files and CI/CD secrets, including the values GitHub Actions tries to mask, read straight from /proc/<pid>/mem. For AI builds specifically: LLM API keys and gateway configuration — the credentials to an organization’s entire AI stack.

Cloud keys were read from the instance metadata service (IMDS) and Kubernetes tokens from mounted service-account paths — no exploit needed, just the access each runner already carried. The loot was sealed with AES-256 under a hard-coded RSA-4096 key, then shipped to a typosquatted domain. Where exfiltration failed, the malware created a public repository in the victim’s own GitHub account and uploaded the stolen data there as a release asset: some organizations were leaking their own secrets into public view without knowing it.

The high-confidence list CloudSEK published commands attention: AWS, Samsung, Salesforce, Cisco, ServiceNow, Siemens, Airbus, X Corp, Zscaler, Epic Games, Orange, Vodafone, NGINX, Deutsche Bahn, FedEx, Volkswagen. CloudSEK is careful about method: these figures describe reconstructed exposure, not proof that every listed organization was successfully compromised.

A 40-minute window, a months-long incident

The malicious package was live for only 40 minutes. That was enough time for automated systems — scheduled jobs, dependency resolvers, ephemeral runners, developer laptops, cached layers — to copy the artifact at machine speed. CloudSEK draws the consequence: removing a package does not close the incident. An artifact disappears in minutes, but copied credentials stay usable for weeks or months unless they are revoked.

That is the point SRE and platform teams must internalize. Rotating a single token — the LiteLLM key or the model provider key — is not enough. Any credential readable by the affected process, present in memory, injected into the job, stored on disk, or retrievable through a metadata service must be treated as potentially exposed until validated. The rotation scope is therefore the whole runner, not the package.

Honesty demands a note on attribution. SOCRadar has since contested part of the count: most of the 2,500 organizations were likely affected earlier, via the Trivy incident itself. The nuance does not change the engineering lesson — it sharpens it: the two incidents are two floors of the same cascade, and the boundary between “Trivy victim” and “LiteLLM victim” is fuzzier than the counts suggest.

What to fix in CI

The LiteLLM compromise reads like a catalog of CI/CD anti-patterns, and every step points to a reversible engineering decision.

Pin build dependencies. The scanner flowed into the build because it was installed unpinned from apt. A security tool is a dependency like any other: it gets versioned, pinned, and verified by hash. Workflow-level locking — the equivalent of a go.sum for your actions — is the structural answer GitHub is building for Actions, but it holds for every pipeline: build containers, scanners, runners.

Revoke, do not just rotate. The “rotated but not fully revoked” token is the pivot of the whole attack. Rotation without revocation leaves the old credential active — exactly the 20-day window exploited here. A credential compromise calls for revocation, then rotation, in that order.

Scope secrets. The stealer needed no exploit: it read the credentials the runner already carried. Least privilege on the GITHUB_TOKEN, no long-lived cloud keys on runners, and restricted Kubernetes service accounts would have mechanically shrunk the haul.

Treat CI as an attack surface. A runner executes untrusted code, handles secrets, and talks to the outside world. It deserves the same monitoring as production: execution telemetry, an egress firewall, and the ability to correlate a network request to a specific job.

Verdict

If your pipelines install Python packages, start with two immediate checks: are your scanners and build tools pinned by hash, and do your runners hold long-lived cloud keys? The LiteLLM breach shows that a “no” to either is a pending exposure, not a theoretical risk.

If you operate a fleet of runners or pipelines, apply the whole-runner rule: when a dependency is compromised, treat every credential accessible to the process — memory, disk, IMDS, service accounts — as exposed, and revoke wide, not narrow.

The rule to remember: in a software supply chain, your security scanner is itself a dependency. Trivy was the weak link that took down LiteLLM, which exposed 434,000 pipelines. The first component to verify in a pipeline is the one that is supposed to verify the others.

References

• LiteLLM Supply Chain Attack: 2,500+ Companies Exposed in the Largest AI Supply Chain Breach of 2026 — CloudSEK, August 11, 2026
• Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack — SecurityWeek
• TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure — Palo Alto Networks Unit 42, March 31, 2026
• Cyber Criminal Group TeamPCP, FLASH-20260702-01 — FBI, July 2, 2026