NeuralWired

LiteLLM Breach 2026: CloudSEK vs Hudson Rock Numbers

LiteLLM Breach: CloudSEK and Hudson Rock Diverge on Scale
Cybersecurity / Supply Chain

LiteLLM Breach: CloudSEK and Hudson Rock Diverge on Scale

Updated August 13, 2026 · 9 min read

Headline options considered:
★ LiteLLM Breach: CloudSEK, Hudson Rock Diverge on Scale
LiteLLM Hack: 2,500+ Firms Named, Credentials Still Live
Inside the LiteLLM Supply Chain Breach, Five Months Later

Two threat intelligence firms just published two different datasets about the same breach, and the numbers almost, but don’t quite, agree. If your organization runs the LiteLLM AI gateway anywhere in your CI/CD pipeline, that gap between “almost” and “exactly” is the part you need to understand today.

On August 11, 2026, CloudSEK published a victim-exposure dataset claiming more than 2,500 organizations and roughly 434,000 CI/CD pipelines were potentially exposed by the LiteLLM supply chain breach. Two days later, Hudson Rock came back with its own numbers, pulled from a separately obtained archive, and they landed close but not identical. That’s not a rounding error. It’s two independent forensic teams checking each other’s work in public, and the small gaps between their findings are as newsworthy as the breach itself.

In this article
  1. What actually happened, in order
  2. The numbers: CloudSEK vs. Hudson Rock
  3. What security researchers are saying
  4. What to check in your own pipeline right now
  5. What’s still unresolved
  6. Frequently asked questions

What actually happened, in order

Strip away the marketing language from both firms’ blog posts and the underlying story is a fairly classic dependency-chain compromise, just with an AI gateway as the final target instead of a bank or a pipeline operator.

The threat group known as TeamPCP first got in through Aqua Security’s Trivy vulnerability scanner, not LiteLLM itself. According to Unit 42’s research, the group used a credential from an earlier late-February breach that hadn’t been fully rotated to hijack Trivy’s service account, then force-pushed malicious code across 76 of 77 version tags in the widely used aquasecurity/trivy-action repository on March 19. Two days later, the same group used stolen GitHub tokens to do the same thing to Checkmarx’s KICS scanner.

LiteLLM was next. Its own incident report confirms that two malicious versions, 1.82.7 and 1.82.8, sat live on PyPI for roughly 40 minutes on March 24, between 10:39 and 11:19 UTC, before being pulled. Version 1.82.8 shipped a file called litellm_init.pth, a mechanism that runs automatically the moment Python starts, regardless of whether a team thought --ignore-scripts was protecting them at install time.

Then came the long silence. The FBI didn’t issue its public advisory, FLASH-20260702-01, until July 2, more than three months after the initial compromise. It formally named TeamPCP and confirmed Trivy, KICS, LiteLLM, and the Telnyx Python SDK as compromised vectors in a single, escalating campaign.

It took another five weeks after that for named-victim-level detail to surface publicly, first from CloudSEK on August 11, then from Hudson Rock and independent researcher Kevin Beaumont on August 13. Nearly five months passed between the original compromise and the point where affected companies could actually see whether they were on a list.

The numbers: CloudSEK vs. Hudson Rock

Here’s where the story gets more interesting than a standard “breach affects X companies” writeup. Both firms say they worked from separately obtained data, and their headline totals are close enough to corroborate each other, but different enough that neither should be treated as the final word.

MetricCloudSEKHudson Rock
Organizations identified2,500+2,488 corporate domains
Underlying scope~434,000 CI/CD pipelines118,829 CI runner dumps
Source archiveConfidential intelligence sources153GB archive, 433,909 files
PublishedAugust 11, 2026August 13, 2026
Notice that CloudSEK’s “434,000” figure and Hudson Rock’s “433,909 files” figure are suspiciously close in raw count, even though one is labeled pipelines and the other is labeled files. Cyber Kendra flagged this directly in its own analysis, arguing the widely repeated pipeline figure may actually describe leaked files or records rather than distinct pipelines, a distinction that changes how any single company should estimate its own exposure.

Why this matters for your risk math Appearing in either dataset means information tied to your organization was identified in leaked material, not that an intrusion into your systems was confirmed. CloudSEK, Hudson Rock, and the FBI advisory all draw that line explicitly. Treat inclusion as a trigger for investigation, not a verdict.

What security researchers are saying

Hudson Rock co-founder and CTO Alon Gal framed the scale of the finding in blunt terms, telling Help Net Security that the size of this dataset demands a genuinely different tier of response from the security industry than incidents of this kind have typically drawn.

Independent researcher Kevin Beaumont pushed back on the framing that AI itself is the villain of this story. In the same Help Net Security piece, he argued the real failure is ordinary DevOps hygiene under pressure to ship AI features fast, not some novel danger inherent to AI systems. That reframe matters because it shifts the accountability conversation from “AI is scary” toward “your credential rotation policy is the problem,” which is a much more actionable takeaway for engineering leadership.

“The LiteLLM supply chain attack is the AI era’s SolarWinds or NotPetya moment.” Craig Alberino, CEO and Co-Founder, APERION · BusinessWire, April 2, 2026
One caveat worth stating plainly: Alberino’s comparison came from a press release tied to the launch of his own company’s competing AI-gateway product, and it included a “36% of all cloud environments” claim that appears in no independent dataset from CloudSEK, Hudson Rock, Unit 42, or the FBI. Read that quote as vendor commentary, not as verified research.

Beaumont also did something more concrete than commentary. He personally tested a major tech company’s public assurance that it had already rotated all exposed credentials, and per the same reporting, found working credentials still active despite that claim. That’s the single most damning, verifiable data point in the entire story, and it’s a preview of what security teams should expect when they audit their own “we already fixed this” statements from March.

What to check in your own pipeline right now

If you’re a DevOps engineer, platform lead, or CISO reading this, the patch-and-move-on instinct doesn’t apply here. Confirming you’re not currently running LiteLLM 1.82.7 or 1.82.8 tells you nothing about whether credentials exposed in March are still sitting active somewhere five months later.

  • Audit CI/CD logs and Docker build history for any install of LiteLLM 1.82.7 or 1.82.8 on March 24, 2026, specifically between 10:39 and 16:00 UTC.
  • Search your site-packages directory for a leftover litellm_init.pth file, which persists even after the package itself is upgraded.
  • Search your GitHub organization for unexpected repositories named tpcp-docs or docs-tpcp, a known artifact of the malware’s fallback exfiltration path.
  • Rotate everything that touched an affected build: cloud IAM keys, SSH keys, Kubernetes service-account tokens, package-publishing tokens, and any AI-provider API keys.
  • Pin GitHub Actions and dependencies to verified commit hashes instead of floating version tags, per the FBI’s own recommended mitigation in FLASH-20260702-01.
Confirmed safe by LiteLLM’s own postmortem: anyone on the official LiteLLM Proxy Docker image, LiteLLM Cloud, or any self-hosted version at 1.82.6 or earlier who didn’t upgrade during the 40-minute window. Versions 1.78.0 through 1.82.6 and 1.83.0 onward were independently SHA-256 verified against Git commits, with Google Mandiant assisting the forensics.

What’s still unresolved

Reporting on this cleanly means resisting the urge to present a single tidy mechanism, because the primary sources themselves don’t agree on one. CloudSEK, LiteLLM’s own team, and Unit 42 each describe the path from the Trivy compromise to the malicious PyPI publish slightly differently, whether it was the poisoned build process itself producing the release, a direct unauthorized upload that bypassed CI/CD entirely, or stolen publishing tokens harvested during the Trivy breach. When asked about the discrepancy, CloudSEK told The Hacker News these were different stages of one attack chain rather than competing explanations, which is a reasonable answer but not the same as a confirmed one.

There’s also an unreconciled figure floating around secondary coverage: some outlets have cited an archive size as large as 195TB for what may be the same or a related dataset, against Hudson Rock’s own stated 153GB. Until one of the primary sources clarifies that gap, treat it as unverified.

Our read: this signals that “responsible disclosure” as a framing is starting to strain under its own timeline. Five months between compromise and named-victim transparency is a long runway for stolen credentials to be resold, reused, or simply forgotten by the teams who should have rotated them.

Frequently asked questions

What is the LiteLLM supply chain attack?
A March 2026 breach in which the threat group TeamPCP compromised the Trivy security scanner used in LiteLLM’s build pipeline, then published two malicious LiteLLM versions, 1.82.7 and 1.82.8, to PyPI for about 40 minutes before they were pulled.

How many companies were affected by the LiteLLM breach?
CloudSEK’s dataset lists more than 2,500 organizations as potentially exposed. Hudson Rock, working from a separately obtained archive, independently identified 2,488 corporate domains. Both figures describe potential exposure, not confirmed intrusion.

Is LiteLLM safe to use now?
Yes, if you’re on version 1.82.6 or earlier, or 1.83.0 and later, all of which BerriAI verified via SHA-256 hashing against Git commits with Google Mandiant’s help. Versions 1.82.7 and 1.82.8 remain compromised and were removed from PyPI.

How do I check if my organization was affected?
Audit CI/CD logs for installs of the two malicious versions on March 24, 2026, check for a leftover litellm_init.pth file, and search your GitHub organization for repositories named tpcp-docs or docs-tpcp.

What is TeamPCP?
A financially motivated group active since at least September 2025 that shifted in 2026 from ransomware toward compromising trusted developer and security tools, including Trivy, Checkmarx KICS, LiteLLM, and the Telnyx Python SDK.

Where this goes next

What’s clear five months in: this wasn’t a LiteLLM problem so much as a trust problem in the tools that sit upstream of nearly every AI deployment pipeline. TeamPCP didn’t need to break LiteLLM’s own defenses. It needed one unrotated credential in a scanner most teams never think about.

Three things worth watching over the next six to eighteen months: whether CloudSEK and Hudson Rock ever formally reconcile their overlapping-but-different datasets, whether regulated industries named in either list face disclosure obligations tied to insurance or compliance frameworks, and whether “pin to commit hash, not floating tag” becomes a default CI/CD posture industry-wide rather than a lesson learned twice.

If your team touched LiteLLM, Trivy, or KICS anywhere in a build process this year, the credential rotation audit isn’t optional. Five months of exposure is a long time for a stolen key to sit around waiting to be used.

Editorial note: An earlier NeuralWired piece referenced a “4TB exposed in under 3 hours” figure tied to LiteLLM and Mercor. That figure does not appear in CloudSEK’s, Hudson Rock’s, Unit 42’s, the FBI’s, or LiteLLM’s own reporting, and this article’s numbers should be treated as the current, sourced account of the breach’s scale.

More posts