LiteLLM Breach: 2,488 Firms in Supply-Chain Map

Thu Aug 13

March 2026 attack / August 2026 victim mapping: Researchers at CloudSEK and Hudson Rock / Infostealers say the TeamPCP compromise of the open-source LiteLLM AI gateway left secrets from roughly 2,488 corporate domains and on the order of 434,000 CI/CD pipeline runs in attacker hands. LiteLLM’s own March security update confirmed malicious PyPI releases. Canonical BreachHistory record: litellm2026-pypi.

If your company ever installed LiteLLM from PyPI—especially versions 1.82.7 or 1.82.8—treat cloud keys, Git tokens, Kubernetes secrets, and LLM API keys that touched those runners as burned until rotated and investigated.

What happened in the LiteLLM supply chain attack

The LiteLLM data breach story did not begin with a dating dump or a ransomware leak site. It began with a poisoned security tool. Public forensics from Snyk, Trend Micro, Cycode, and others describe TeamPCP first compromising the GitHub Actions pipeline for Trivy, a widely used open-source vulnerability scanner. Because LiteLLM’s own CI used Trivy, the attackers obtained legitimate runner access and stole LiteLLM’s PyPI publishing tokens.

Armed with those tokens, TeamPCP published malicious LiteLLM packages. The payload used a Python .pth startup hook so malicious code could run when the interpreter started—not only when an application explicitly imported LiteLLM. Stealers tracked in industry reporting (including Google’s SANDCLOCK naming in CloudSEK coverage) escalated on CI runners, swept environment variables, cloud credential files, Kubernetes configs, SSH keys, package-publishing credentials, and AI provider keys, then exfiltrated encrypted loot to attacker infrastructure. In some cases, where outbound exfiltration failed, malware reportedly created a public repository inside the victim’s own GitHub account and uploaded stolen data as a release asset—turning the victim’s account into the leak channel.

LiteLLM removed the malicious versions and published remediation guidance. That was not the end of the incident. Copied credentials remain useful until rotated, and FBI FLASH guidance cited in CloudSEK’s August write-up warned that affiliated actors may weaponize harvested secrets long after the original package is gone.

The August disclosure: 2,488 firms and ~434,000 pipelines

What changed the public narrative in August 2026 was not a new PyPI trojan—it was victim mapping. CloudSEK described reconstructing exposure across more than 2,500 organizations and about 434,000 CI/CD pipelines. Hudson Rock’s Infostealers analysis of a large archive independently attributed 118,829 CI runner dumps to 2,488 affected corporate domains, with a corpus on the order of 153 GB / ~433,909 files. Named examples in researcher dashboards included major technology brands; defenders should treat those lists as research attributions requiring private validation, not as court findings.

BreachHistory indexes the LiteLLM row with the researcher-attested organizational scale (~2,488 firms) while emphasizing methodology caveats CloudSEK itself stresses: reconstructed exposure is not proof that every listed company executed malware or that every credential was stolen. Public wording for many victims should remain “potentially exposed” until internal logs confirm malicious execution or exfiltration.

What data and secrets were at risk

This was primarily a secrets and infrastructure breach, not a classic consumer PII dump. Categories repeatedly described across vendor write-ups include:

AWS, GCP, and Azure credentials and cloud tokens
GitHub / GitLab / Bitbucket PATs and deployment tokens
SSH keys and Kubernetes service-account material
Package-publishing credentials (npm, PyPI, and related)
Environment variables and .env contents from CI runners
LLM API keys and AI gateway configuration—the keys to an organization’s AI stack
Database and internal JWT-style secrets in unattributed runner dumps

Downstream business impact depends entirely on what those secrets unlocked: source-code access, cloud spend fraud, production data exfiltration, or further supply-chain publishing. That is why the LiteLLM supply chain attack sits next to other 2026 package compromises—Trivy/Cisco CI fallout, npm worm waves, and AI-gateway dependency risk—in BreachHistory’s catalog.

Who is at risk

Engineering and platform teams that pinned LiteLLM 1.82.7/1.82.8 in applications, containers, or developer laptops. Security teams that assumed “we only use Trivy to scan” without realizing Trivy’s own CI compromise could seed publishing-token theft upstream. AI platform owners whose LLM keys lived in the same runners as build secrets. Compliance and board stakeholders at firms that marketed SOC 2 / ISO attestations next to LiteLLM—press also covered governance friction around compliance vendors after the malware event.

If you are a customer of a SaaS vendor that embeds LiteLLM, you may never see the package name—yet that vendor’s cloud keys may still appear in the reconstructed corpora. Ask vendors whether they audited for the malicious versions and rotated CI secrets.

How the attack chain worked (defender summary)

Compromise a trusted scanner’s CI (Trivy) to steal publishing credentials of a dependent project.
Publish malicious LiteLLM versions to PyPI using stolen tokens.
Execute stealthily via interpreter startup hooks on developer and CI hosts.
Harvest secrets at root on runners; exfiltrate or dump into the victim’s public GitHub releases.
Retain credentials for later campaigns—removal of the package does not revoke stolen IAM keys.

That multi-hop pattern is why “largest AI supply chain breach of 2026” headlines stuck: the blast radius is measured in organizations and pipelines, not in a single consumer email list.

What LiteLLM and researchers said

LiteLLM’s March security update documented the suspected supply-chain incident and remediation. Independent technical deep-dives from Cycode, Snyk, NetSPI, HeroDevs, and Trend Micro mapped payload behavior. CloudSEK and Hudson Rock later published victim-scale research and ethical-disclosure tooling so companies can check domain exposure. BreachHistory treats the PyPI compromise as confirmed malicious packaging and the ~2,488-firm figure as researcher-attested exposure mapping, not a GDPR-style individual census.

Action items after the LiteLLM breach

Inventory every environment for LiteLLM 1.82.7 and 1.82.8; rebuild from clean pins (1.82.6 or later patched lines per vendor guidance).
Assume CI secrets reachable by those runners are compromised—rotate cloud IAM keys, K8s tokens, Git PATs, and LLM API keys.
Search GitHub/GitLab for unexpected public repos or release assets created during the incident window.
Review outbound network logs from CI for typosquatted exfil domains named in vendor reports.
Check CloudSEK / Hudson Rock disclosure tools if your domain may appear in the reconstructed set—then validate privately with logs.
Lock down package publishing: hardware-backed tokens, short TTL, and anomaly alerts on PyPI/npm publishes.
Treat “security scanner in CI” as high-trust code—apply the same controls you would to a deploy key.
Brief executives: this is a secrets incident that can become a customer-data incident if stolen cloud keys reached production datastores.
Update SBOM and dependency-allowlist processes so a single poisoned transitive tool cannot republish your packages.
Track FBI / national CERTs for follow-on advisories about credential reuse from this campaign.

Industry context

2026’s supply-chain year already included npm worm campaigns, AUR package hijacks, and scanner-poisoning narratives. LiteLLM sits at the intersection of AI infrastructure popularity and CI secret sprawl. Related BreachHistory rows include Cisco/Trivy CI compromise reporting and Mercor’s public statement tying its incident to the LiteLLM chain. The lesson for AI teams is blunt: gateway packages inherit the trust of every secret on the runner that installs them.

Timeline: from Trivy poison to August victim maps

Defenders reconstructing the LiteLLM supply chain attack should separate three clocks. First is the upstream CI compromise of Trivy and theft of publishing credentials—the quiet phase. Second is the malicious PyPI window when 1.82.7 and 1.82.8 could be installed by unsuspecting pipelines worldwide. Third is the disclosure and mapping phase in which CloudSEK, Hudson Rock, and others published organizational exposure estimates and ethical look-up tooling months after the packages were yanked.

That third clock is why August 2026 headlines revived a March incident. Boards that closed the ticket in April after “we unpinned the bad versions” are discovering that credential inventories were incomplete. FBI FLASH language about later weaponization of harvested secrets is the operational punchline: supply-chain malware is a secrets problem with a long tail.

For incident responders writing chronologies, log the first date your environment resolved 1.82.7/1.82.8, the last CI job that could have imported them, and every secret class those jobs could read. That matrix—not the blog post word count—determines whether you notify customers or only rotate build keys.

Why AI gateways concentrate blast radius

LiteLLM popularized a simple idea: one proxy to many model providers. The security corollary is that the proxy’s runtime often holds every provider key plus whatever cloud identity the gateway uses to pull configs. Put that process on a CI runner that also deploys infrastructure-as-code, and a single stealer pass captures AI spend keys and production cloud keys together.

Comparable 2026 patterns showed up in MCP-related advisories and other AI-agent dependency scares: tooling that sits in the middle of automation inherits maximal trust. The LiteLLM breach is the clearest public example that “we only use it in staging” fails when staging runners share org-wide GitHub tokens or when developers pip install the same package on laptops with AWS SSO caches.

Enterprises building private AI stacks should assume gateway packages are tier-0 dependencies—subject to the same review, pinning, and provenance controls as Terraform providers or container base images.

Methodological caution on the 2,488 figure

CloudSEK is explicit that reconstructed exposure datasets need confidence labels. A domain appearing beside runner dumps is a lead for private validation, not automatic proof of customer-data theft. Hudson Rock’s independent archive analysis converging near the same organizational order of magnitude increases confidence in scale while still leaving room for false attribution where runners lacked clear org metadata.

BreachHistory therefore describes ~2,488 firms as researcher-mapped corporate domains and ~434,000 pipelines as reconstructed CI exposure—not as a GDPR personal-data census. If your CISO asks “were we breached?”, the honest answer is: check whether malicious versions executed in your estate and whether secrets from that estate appear in disclosed corpora; do not outsource that determination to a marketing table.

Compliance and assurance fallout

March press also examined compliance vendor relationships around LiteLLM’s certifications. Separately indexing that governance controversy (see Delve/LiteLLM blog context on BreachHistory) matters because customers often equate “SOC 2 badge” with “supply chain immune.” The LiteLLM episode shows attestations do not stop stolen publishing tokens. Organizations should ask AI vendors how they protect package-publish credentials, whether CI uses short-lived OIDC, and how quickly they can revoke PyPI tokens after anomaly detection.

Downstream startups that embedded LiteLLM—and later faced extortion or leak claims of their own—illustrate secondary harm: Mercor’s public discussion tying its incident to the LiteLLM chain is the cautionary tale for every AI hiring or agent platform that vendors a gateway they do not fully control.

Practical detection ideas

Package inventories and container SBOMs for litellm==1.82.7|1.82.8
CI logs showing unexpected root escalations or new systemd units on runners
Git audit logs for repositories created outside normal IaC patterns during the window
CloudTrail / Azure Activity / GCP Admin logs for keys that only ever lived in CI
LLM provider dashboards for sudden key use from unfamiliar geos

Pair detection with a revocation runbook that can rotate hundreds of keys without waiting for a perfect forensic narrative. Speed beats elegance when stealers already shipped archives.

What “good” looks like after an AI supply-chain hit

Mature programs will treat the LiteLLM event as a forcing function: pin hashes, enforce admission controllers that block unknown PyPI artifacts, separate AI gateway identities from cloud-admin roles, and require dual control for package publishing. They will also tabletop a scenario where a security scanner’s CI is the beachhead—because that is exactly how this campaign reportedly started.

If you only change one architectural habit, make it this: no long-lived cloud key on any host that installs unverified AI packages. Workload identity and short-lived tokens turn a stealer from “game over” into “annoying rotation.”

FAQ: was I affected by the LiteLLM hack?

Developers: check lockfiles and container images for 1.82.7/1.82.8; if present, rotate everything those environments could touch. Security leaders: query CloudSEK/Hudson Rock look-ups as a lead, then confirm with CI logs—do not notify customers solely because a domain appeared in a research table. Customers of AI vendors: ask whether vendors used LiteLLM during the malicious window and whether they rotated provider keys. Open-source maintainers: audit who can publish to package registries; stolen tokens were the hinge of this campaign.

Searching “LiteLLM data breach 2026” or “LiteLLM supply chain attack 2488” should land you on primary vendor advisories and the BreachHistory canonical row—not on recycled forums that invent consumer Social Security dumps. This incident’s core harm is credential theft at industrial scale.

Finally, schedule a 30-day and 90-day review: stealers often enable quiet follow-on access weeks later. If you only rotated keys once in March and never reviewed GitHub audit logs, August’s research dump is your reminder to finish the job.

Bottom line for engineering leaders

The LiteLLM supply chain attack is the clearest 2026 case study that AI tooling popularity plus CI secret sprawl equals enterprise exposure measured in thousands of firms. Unpinning malware is necessary and insufficient. Rotate secrets, audit Git for self-leaks, harden publishing tokens, and assume TeamPCP-style actors will keep reusing what they already stole. BreachHistory will revise the LiteLLM catalog row if vendors publish cleaner censuses or if new malicious versions appear.

Canonical record and sources

Canonical page: 2026 LiteLLM — TeamPCP PyPI supply chain; ~2,488 firms / ~434K CI pipelines (researcher mapping).

Sources: LiteLLM security update, CloudSEK, Infostealers / Hudson Rock, Cycode, Snyk, BleepingComputer.

Updated 2026-08-13 with August victim-mapping research.