One unrevoked token, sitting in the release pipeline of a vulnerability scanner, ended up spilling secrets from Nvidia, AWS, Samsung, FedEx, Volkswagen and roughly 2,480 other organizations. CloudSEK has finished attributing the data stolen in March's LiteLLM compromise, and the number that should worry you is not 2,488 companies. It is 40 minutes.

That was the entire window the poisoned LiteLLM packages sat on PyPI before they were pulled. Forty minutes was enough to reach an estimated 434,000 CI/CD pipelines and produce 118,829 CI runner memory dumps, because nothing in a modern Python build waits around. Every pipeline that resolved LiteLLM in that window ran the payload before a single line of application code executed.

RelatedNvidia's Open Secure AI Alliance Launches, Minus OpenAI

How does a scanner compromise become an AI gateway compromise?

LiteLLM was never targeted. The threat actor CloudSEK tracks as TeamPCP, already tied to several open source compromises this year, went after Aqua Security's Trivy, the vulnerability scanner that an enormous number of teams run as a build step. LiteLLM's own CI pipeline installed Trivy automatically, unpinned, on every run. When a compromised Trivy release shipped, LiteLLM's build environment ingested it, the attacker picked up LiteLLM's publishing credentials, and malicious code went out as versions 1.82.7 and 1.82.8 on PyPI.

CloudSEK's summary of the chain is the most quotable line in the whole report: "one unrevoked token, three tools deep." Nobody in that sequence was careless in an obvious way. LiteLLM trusted its scanner. Downstream users trusted LiteLLM. The trust was transitive, and so was the compromise.

The LiteLLM supply chain attack path, from Trivy to 434,000 pipelines Flow diagram. TeamPCP compromised the Trivy scanner. LiteLLM continuous integration auto-installed the poisoned Trivy build. That leaked LiteLLM publishing credentials, which pushed malicious versions 1.82.7 and 1.82.8 to PyPI. Those packages were live for 40 minutes and reached an estimated 434,000 CI/CD pipelines across 2,488 corporate domains, producing 118,829 runner memory dumps. THREE TOOLS DEEP Nobody attacked LiteLLM. They attacked what LiteLLM trusted. TeamPCP threat actor Trivy scanner release LiteLLM CI unpinned install PyPI 1.82.7 / 1.82.8 live for 40 minutes 434,000 CI/CD pipelines reached 2,488 corporate domains · 118,829 runner memory dumps WHAT CAME OUT OF THE RUNNERS Cloud keys SSH keys Registry tokens AI provider keys Env vars Treat any secret readable by the LiteLLM process as compromised. genztech.blog
Fig 1 The compromise moved through three layers of ordinary, reasonable trust before it reached anyone's build.

Why did 40 minutes do this much damage?

Because CI is the perfect amplifier. A human developer installing a bad package gets one workstation compromised. A poisoned package that lands in continuous integration gets executed by every branch push, every pull request, every scheduled job, in an environment that by design holds the credentials needed to build, test and deploy. CI runners are where organizations concentrate their most powerful secrets and then run untrusted dependency graphs against them.

The malicious LiteLLM code executed on every Python invocation, not just at install time. That distinction matters. It meant the payload did not need the build to succeed, or the tests to pass, or anyone to notice. It just needed the interpreter to start.

And LiteLLM is a particularly unlucky place for this to happen. It is the proxy layer a great many teams put in front of OpenAI, Anthropic, Google and their own self-hosted models, which means the environments running it hold exactly the credentials an attacker wants: provider API keys with real spending authority attached.

 TrivyLiteLLMYour pipeline
Directly targeted?YesNoNo
Needed a CVE?NoNoNo
Compromise routeActor accessUnpinned depVersion resolution
Window to reactDaysMinutesNone
Would a scanner catch it?n/aNoNo

That last row is the uncomfortable one. The compromised artifact was a vulnerability scanner. Scanning would not have saved you, because scanners check for known-bad versions and this was a brand new, signed, legitimately published release from an account the ecosystem had every reason to trust.

Who is actually affected?

CloudSEK named a cross-section that makes the point better than a percentage would: Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX and Zscaler. Several of those are security vendors. At least one of them sells supply chain security.

Being on that list does not mean an organization was breached in any deeper sense. It means secrets from its build environments turned up in the attacker's collection. What happened next depends entirely on whether anyone rotated them in the five months since March, and the honest answer for most of these environments is that nobody knew there was anything to rotate until this week.

RelatedCrypto Hacks Hit $1.32B in H1 2026, CertiK Warns

  1. March 2026TeamPCP compromises a Trivy release Nobody downstream is aware
  2. March 2026LiteLLM CI ingests it, credentials leak Automated, no human in the loop
  3. +40 minlitellm 1.82.7 and 1.82.8 pulled from PyPI Damage already done
  4. Aug 12, 2026CloudSEK attributes 118,829 dumps to 2,488 domains First real measure of scale
  5. NowRotation window for five-month-old secrets Assume they are still live until proven otherwise

What should you actually do today?

If LiteLLM appeared anywhere in your dependency tree in March, the guidance is blunt: treat every secret that was readable by that process as compromised, and rotate it. That means cloud access keys, SSH keys, package registry publishing tokens, database connection strings, and every AI provider key in the environment. Validate service accounts while you are in there, and pull CI logs from the period to scope what actually ran.

The structural fix is duller and more valuable. Pin your build tooling to hashes rather than floating tags, so a fresh malicious release cannot enter through a version range you never reviewed. Scope CI credentials down to the job that needs them instead of exposing the full environment to every step. And give publishing tokens short lifetimes, because the difference between this being an incident and a catastrophe was largely how long the stolen credentials stayed valid.

What it means for the market

The signal for investors is not that any single vendor failed. It is that the AI tooling layer has inherited the software supply chain's oldest structural weakness at a moment when that layer is being adopted faster than it is being hardened. Zscaler and Cisco both appear on the exposure list while selling security to enterprises, which is less an indictment than a demonstration that nobody has solved this. Watch whether enterprise buyers start writing dependency provenance requirements into AI infrastructure contracts. That is where the spending shifts if this pattern repeats, and it has now repeated several times in 2026 alone.

What to watch · next 6 months
  • Credential half-life becomes the metric. The interesting number in the next incident will not be how many packages were poisoned, but how long the stolen tokens stayed valid.
  • Build tooling gets treated as production. Scanners, linters and formatters run with real credentials and almost no scrutiny. Expect that to be where the next one lands too.
  • AI gateways are now high-value targets. Anything holding provider keys for several frontier labs at once is worth more to an attacker than the application it fronts.
  • Attribution keeps lagging by months. March to August is the gap between compromise and knowing who was hit. Assume that gap exists right now for something else.

Our take

The reflex after an incident like this is to demand that maintainers do better, and that reflex is misplaced here. LiteLLM's maintainers did a normal thing, which was to run a security scanner in CI. The scanner was the attack. There is no amount of individual diligence that survives a trusted dependency turning hostile mid-chain.

What is genuinely fixable is the blast radius. Forty minutes of exposure should not be able to reach 434,000 pipelines, and it only did because the default posture of CI is to resolve the newest thing, run it immediately, and hand it every secret in the environment. That default is a choice, and it is one most teams have never consciously made. The lesson from LiteLLM is not to trust less. It is to make sure that when trust fails, it fails narrowly.

Primary sources

Analysis by GenZTech, built from CloudSEK's attribution data as reported by SecurityWeek.