LiteLLM's 40 minutes on PyPI: 153GB of loot, 2,488 named orgs, and the victims nobody can name

On August 12, 2026, Hudson Rock published its analysis of the archive stolen during March's compromise of the litellm package on PyPI: a 153GB RAR containing 433,909 files ^[2]. CloudSEK published parallel victim research a day earlier, on August 11, from its own intelligence sources ^[4]. That matters because the malware behavior was already documented in March ^[5]; what was missing was the count. GitGuardian, which reported in March that the blast radius was likely significant, notes that was an inference from malware analysis, and the archive replaces it with numbers ^[21].

The numbers: Hudson Rock attributed 118,829 CI runner dumps to 2,488 corporate domains ^[3]. That is an average of roughly 47.8 dumps per organization ^[18], and runner dumps account for about 27 percent of the files in the archive ^[19]. The malicious version was live on PyPI for about 40 minutes ^[1].

What each dump contains is the part worth reading twice. On compromised runners the payload escalated to root and swept SSH keys, AWS, GCP and Azure credentials, Kubernetes service account tokens, .env files and CI/CD secrets ^[6]. On AI builds it also took LLM API keys and gateway configuration, which per GitGuardian is access to an organization's whole model stack rather than a single credential ^[7]. Hudson Rock's write-up shows environment dumps captured mid-execution, including AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, SLACK_SIGNING_SECRET, Azure environment credentials and AI provider API keys ^[8]. In one case Hudson Rock reports a single organization with 17 compromised pipeline dumps exposing Bitbucket deployment tokens, Elastic API keys, internal JWTs and NPM tokens ^[10]. Publishing credentials in the loot is how one supply chain incident seeds the next ^[11].

The unattributable share is the finding operators should sit with. Hudson Rock puts no 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, which makes them impossible to trace to an owner ^[12]. Attribution in this archive depends on incidental variables such as GITLAB_USER_EMAIL and CI_SERVER_FQDN ^[9]. Hudson Rock ran an ethical disclosure program and CloudSEK published a public lookup tool, and neither can notify a company it cannot name ^[13].

Even the named cases can misroute. 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 exposure sat in AdsWizz infrastructure, a SiriusXM subsidiary, so an alert routed on the email alone reaches the wrong security team ^[14].

Two operational details cut against repository-centric hygiene. The payload ran at Python interpreter startup, on developer laptops as readily as CI runners, and never touched a repository ^[15]. And GitGuardian's own remediation guidance, which is vendor guidance, asks which credentials lived in those pipelines on March 24 ^[17], and recommends a non-human identity inventory, endpoint secrets detection, continuous detection with validity checking, and honeytokens in environment variables that alert on first use without the victim needing to be identified first ^[16].

Watch whether either firm quantifies the unattributable slice, and whether the NPM and Bitbucket tokens in the loot show up as downstream package publishes.