LiteLLM breach exposes secrets linked to nearly 2,500 organisations

Security researchers have obtained a 153GB archive containing credentials allegedly stolen during the March LiteLLM supply-chain attack. The data reportedly links to almost 2,500 organisations, including AWS, Cisco, Samsung, Salesforce and other major companies.

The LiteLLM breach archive contains cloud credentials, access tokens, AI provider keys and other sensitive data. However, exposure in the dataset does not confirm that attackers accessed every affected company or used every stolen credential.

Archive contains hundreds of thousands of files

Threat intelligence firms CloudSEK and Hudson Rock say the archive contains 433,909 files. Hudson Rock attributed 118,829 CI runner dumps to 2,488 corporate domains.

The dataset reportedly includes AWS secret access keys, Microsoft Azure credentials, Salesforce tokens, Kubernetes service account tokens, SSH keys, GitHub and GitLab access tokens, environment files and AI API keys.

Attackers behind the LiteLLM supply-chain attack reportedly designed the malicious package to collect data from live environments. When developers installed or ran it, the malware could search process memory, configuration files and CI/CD runner environments for secrets.

AI gateways often handle highly privileged credentials because they connect models, cloud services, development pipelines and internal systems. That makes a compromise of this kind particularly serious.

Researchers warn some keys may still work

CloudSEK stressed that stolen credentials do not prove a further compromise. Attackers may never use some keys, while organisations may have already rotated others.

Still, researchers warn that exposed secrets can remain valid for weeks or months if companies do not revoke them quickly.

Security researcher Kevin Beaumont said he reviewed the leaked data and found it legitimate. He also tested a group of credentials from March and found that many still worked, despite one affected organisation saying it had rotated them.

That finding highlights the risk of treating a supply-chain incident as a one-time event. Attackers can return to stolen credentials long after the initial breach if organisations leave them active.

The FBI warned in July that TeamPCP, the group linked to the LiteLLM attack, and related actors could continue to weaponise stolen credentials.

Organisations should rotate every exposed secret

Any organisation that ran the affected LiteLLM environment should assume that attackers accessed all secrets available to the process.

Security teams should immediately revoke and rotate cloud IAM keys, AI provider keys, Kubernetes tokens, SSH keys and GitHub or GitLab personal access tokens. They should also rotate credentials stored in .env files, CI/CD variables and instance metadata services.

Rotating only the LiteLLM or model-provider key is not enough. Attackers may have collected any secret that the compromised process could read from memory, disk, injected environment variables or cloud metadata services.

Teams should also examine authentication logs, CI runner activity and cloud audit trails for unusual behaviour. They should look for new accounts, unexpected API requests, suspicious outbound traffic and other signs of persistence.

AI infrastructure creates a high-value target

The LiteLLM breach shows why organisations must treat AI infrastructure as privileged infrastructure.

AI gateways often sit between data, identity, cloud resources and automated actions. They also depend on large software stacks and may run with broad permissions.

Companies should restrict which secrets AI services can access, isolate CI/CD runners, enforce short credential lifetimes and limit outbound network connections. They should also monitor model gateways and build systems with the same attention given to production identity platforms.

The full effect of the LiteLLM breach may take months to emerge. For organisations in the leaked dataset, rapid credential rotation and a thorough compromise review remain the most important next steps.