LiteLLM breach archive totals 153GB of secrets from 2,488 organizations

The scale, now measured

Five months after attackers compromised the litellm package on PyPI, researchers have put hard numbers on what was stolen. According to an analysis published by Hudson Rock on August 12, 2026, the attackers exfiltrated a 153GB RAR archive holding 433,909 files during the roughly 40-minute window in March when the tampered package was live. CloudSEK published parallel research on August 11, 2026, covering the same campaign from its own intelligence sources, and a GitGuardian writeup on dev.to summarizes both reports.

Within the archive, Hudson Rock attributes 118,829 CI runner dumps to 2,488 corporate domains. The two reports focus on the stolen data rather than the malware's behavior, which had already been documented when the incident came to light in March.

How the credentials were harvested

On every compromised runner, the payload escalated to root and swept SSH keys, AWS, GCP and Azure credentials, Kubernetes service account tokens, .env files and CI/CD secrets. On AI-related builds it also collected LLM API keys and gateway configuration, which in practice means access to an organization's entire model stack rather than a single credential.

Hudson Rock's report shows environment dumps captured mid-execution, including AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, SLACK_SIGNING_SECRET, Azure credentials and AI provider API keys. Fields such as GITLAB_USER_EMAIL and CI_SERVER_FQDN are what make attribution possible at all. One organization accounted for 17 compromised pipeline dumps, exposing Bitbucket deployment tokens, Elastic API keys, internal JWTs and NPM tokens, the sort of haul that can convert one supply-chain incident into the next.

The payload also ran at Python interpreter startup, so it executed on developer laptops as readily as on CI runners, and it never touched a repository. That detail matters for any team scoping its investigation around source control alone.

The victims nobody can name

The sharpest finding in either report is a negative one. Hudson Rock reports that many dumps contain live database passwords, cloud credentials and third-party API keys, yet carry 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. Hudson Rock ran an ethical disclosure program and CloudSEK published a public lookup tool, but neither can notify a company it cannot name.

Attribution can also 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 compromise actually sat in AdsWizz infrastructure, a SiriusXM subsidiary, so an alert routed on the email alone would have reached the wrong security team.

What exposed teams can do

• Build an inventory of non-human identities: which credentials existed in pipelines on March 24, what each one reaches and who owns it. Without that list, the question of whether an organization was exposed has no answer.
• Extend monitoring to endpoints. Because execution happened at interpreter startup, developer machines are as much in scope as CI runners.
• Run continuous secrets detection with automated validity checks, turning a vague worry into a ranked list of credentials to rotate.
• Place honeytokens in environment variables and .env files. The first attempted use triggers an alert, a signal that arrives without anyone having to identify the victim first.

Why it matters

Supply-chain incidents are usually measured in downloads or affected package versions; this one is measured in gigabytes of live credentials and named victims. The LiteLLM archive demonstrates both halves of the problem: how much an infostealer can extract from CI in under an hour, and how disclosure breaks down when victims leave no return address. Any team that ran litellm builds in March, especially around March 24, should assume exposure until its own credential inventory says otherwise, because for a large share of victims no one else will ever notify them.