40 Minute LiteLLM Hack Exposes Cloud Keys and CI/CD Secrets From 2,488 Companies

A supply-chain breach involving LiteLLM has widened from a compromised software release into an exposure event affecting thousands of corporate build environments.

The incident shows how one poisoned dependency can reach far beyond its original project, placing cloud access and deployment credentials within reach of attackers.

The attack path reportedly started with a compromise of the Trivy scanning tool used in LiteLLM’s build process.

Malicious code was then able to run in automated CI/CD environments, where it searched for credentials that developers and services need to build, test and deploy software.

HudsonRock analysts identified a 153GB archive linked to the campaign, containing 433,909 files and 118,829 CI runner dumps tied to 2,488 corporate domains.

HudsonRock said in a report shared with Cyber Security News (CSN) that the material points to a serious exposure of build-time secrets rather than proof that every named organization suffered a completed intrusion.

The scale matters because CI/CD runners often hold powerful, short-lived or long-lived credentials.

A stolen cloud key, repository token or signing secret can let an intruder alter code, access infrastructure or move deeper into an organization without first breaking into an employee account.

40 Minute LiteLLM Hack

The reported 40-minute window underlines the speed of automated supply-chain abuse.

Once the malicious component reached a runner, it could inspect its environment and collect data before routine jobs finished, leaving defenders with little visible warning.

This is why the earlier LiteLLM supply chain attack deserves renewed scrutiny.

The recovered records reportedly include AWS credentials, GitLab identities, Azure secrets, API tokens, configuration files and keys for AI services.

The alleged haul also contains access material for collaboration and business platforms.

Such credentials do not automatically grant unrestricted access, but they can give attackers a direct starting point into cloud accounts, code repositories and internal services.

The attack did not need to target each company one by one. It allegedly abused trust in a shared developer tool, a pattern also described in coverage of the compromised Trivy scanner incident.

That approach turns a central build dependency into a distribution point and can expose many organizations at once. The attribution and victim list should still be handled carefully.

HudsonRock’s findings are based on an archive it says it obtained and analyzed, while the presence of a domain or runner record alone does not establish data theft, persistence or follow-on misuse at that organization.

Affected teams should validate exposure through their own logs, runner history and cloud audit records.

What Security Teams Should Do Now

Organizations that used LiteLLM versions 1.82.7 or 1.82.8, or ran the affected tooling in the relevant period, should treat every secret available to those runners as potentially exposed.

The first priority is rotation: replace cloud access keys, repository tokens, SSH keys, signing credentials, Kubernetes tokens and AI-provider keys, then revoke the old values.

Teams should also review build logs, workflow definitions and runner images for unexpected commands, unfamiliar outbound connections or changes to dependencies.

Security staff can use the lessons from TeamPCP pipeline credential theft to focus an investigation on the credentials and files most commonly present in automated jobs.

The longer-term response is to reduce what a build runner can access. Use short-lived credentials where possible, separate production from testing environments, limit each token to the smallest practical permission set and keep secrets out of plain environment files.

Pinning dependencies to verified versions or commit hashes can also make unauthorized replacement easier to spot.

Finally, organizations should inventory every pipeline that used the affected packages and preserve logs before retention limits erase them.

The broader warning echoes the CISA supply-chain attack guidance: a build system is not only a delivery tool. It is a high-value security boundary that must be monitored, isolated and prepared for rapid credential replacement.

That discipline can limit damage from the next trusted-tool compromise.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world