Inside the LiteLLM hack: 153GB, 433,909 Files, 2,488 Organizations

Hudson Rock published an analysis of a 153GB exfiltration archive containing 433,909 files stolen during the March compromise of the litellm package on PyPI, attributing 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK released parallel victim research covering the same campaign. The reports found that many stolen dumps contained live database passwords, cloud credentials, and third-party API keys with no attributable company email or domain, meaning affected organizations may never be identified or notified.

Attackers dumped everything they harvested from LiteLLM builds during a 40-minute window in March. Here is what is inside and what it says about where secrets live. The March compromise of litellm lasted about 40 minutes on PyPI. This week we learned what the attackers stole in that time. On August 12, 2026, Hudson Rock published its analysis https://www.infostealers.com/article/largest-ai-supply-chain-breach-of-2026-litellm-hack-impacts-thousands-of-global-enterprises-claim-your-ethical-disclosure/ of the exfiltration archive: a 153GB RAR containing 433,909 files. Its researchers attributed 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK published parallel victim research https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines on August 11, covering the same campaign from its own intelligence sources. Neither report is about malware behavior. That was documented in March. These are about the loot. In March we wrote https://blog.gitguardian.com/litellm-supply-chain-attack/ about the LiteLLM supply chain attack when the infostealer harvested everything an attacker could want. We listed SSH keys, cloud credentials, Docker configuration, and crypto wallet data, and said the blast radius was likely significant. That was an inference from malware analysis. The archive turns it into counts. On each compromised runner, the payload escalated to root. It swept SSH keys, AWS, GCP, and Azure credentials, Kubernetes service account tokens, .env files, and CI/CD secrets. On AI builds, it also took LLM API keys and gateway configuration, which is access to an organization's entire model stack rather than one credential. In March we said the keys to your infrastructure were potentially in the hands of threat actors. Five months later, the qualifier is gone. 118,829 runner dumps, 2,488 organizations, one 40-minute window. Hudson Rock's write-up shows environment dumps captured mid-execution: AWS SECRET ACCESS KEY SALESFORCE CLIENT SECRET SLACK SIGNING SECRET GITLAB USER EMAIL and CI SERVER FQDN , which is how attribution can be done In one example, Hudson Rock reports a single organization with 17 compromised pipeline dumps exposing Bitbucket deployment tokens, Elastic API keys, internal JWTs, and NPM tokens. Publishing credentials in the loot is how a supply chain incident becomes a second supply chain incident. The most useful finding in either report is a negative one. Hudson Rock does not put a number on it, but reports that many dumps carry live database passwords, cloud credentials, and third-party API keys with no company email, no custom domain, and no internal hostname. Those records cannot be attributed to anyone. The organizations behind them will appear on no victim list and will receive no disclosure email. Attributed records can still mislead. Hudson Rock describes a pipeline whose committer email ended in @siriusxm.com , while the environment dump pointed to gitlab.adswizz.com and a matching registry host. The breach sat in AdsWizz infrastructure, a SiriusXM subsidiary. Routing an alert on the email alone reaches the wrong security team. Hudson Rock ran an ethical disclosure program. CloudSEK published a public lookup tool. Neither can notify a company it cannot name. Responsible disclosure needs an address, and a generically configured runner does not leave one. Good intentions do not close that gap. If disclosure cannot reach you, detection has to start in your own environment. An inventory of your non-human identities https://blog.gitguardian.com/tag/nhi/ tells you which credentials lived in those pipelines on March 24, what each one reaches, and who owns it. Without that list, "were we exposed" has no answer. The payload ran at Python interpreter startup, on developer laptops as readily as on CI runners. It never touched a repository. Developer Endpoint Protection http://gitguardian.com/developer-endpoint-protection extends secrets detection to the machines where code actually executes, which is where this campaign collected everything it collected. Continuous secrets detection https://www.gitguardian.com/monitor-internal-repositories-for-secrets with automated validity checking turns "we might be in there somewhere" into a ranked list of credentials to rotate today. This stealer collected environment variables and .env files, which is where honeytokens https://www.gitguardian.com/honeytoken sit. The first time an attacker tries one, you get an alert. That signal reaches you without anyone having to identify you first, which is the gap this archive exposes.