Will it run?
Security

Supply-chain attack on LiteLLM exposed terabytes of credentials

By Rae Whitlock Clawpit staff
Supply-chain attack on LiteLLM exposed terabytes of credentials

Terabytes of access tokens, cloud keys, repository tokens, SSH keys, Kubernetes secrets, package-publish permissions, environment variables and AI-provider credentials were exposed in a supply-chain attack on LiteLLM, an open-source tool that streamlines AI-driven development. The list of affected organizations includes Microsoft, Amazon, Cisco, Samsung, Salesforce and about 2,500 additional organizations, according to security firms CloudSec and Hudson Rock in reports published in the past two days.

The leak occurred during a 40-minute window in March, when victims downloaded compromised versions of LiteLLM from its official PyPI repository. Hudson Rock arrived at its conclusions after analyzing a 195-terabyte file that came into its possession, although the companies did not disclose the file’s origin. That figure alone demonstrates the scope of material collected, encompassing not only individual keys but massive documentation of build environments.

The breach of LiteLLM was not isolated; it was the result of a prior attack that infected the widely used vulnerability scanner Trivy. The same campaign also compromised KICS and Telnik’s Python SDK. Credit for the operation was claimed by the Timphisipi team, a loosely organized group whose members are mostly teenagers, and independent researchers largely corroborated the claim.

Independent researcher Kevin Bummont confirmed the data as authentic after cross-checking with several affected organizations. He said the repository contains a significant amount of sensitive material and the breach stems from poor DevOps security in organizations rushing to release AI capabilities, not because AI itself is a threat, adding that “teenagers can run around such organizations in circles.”

The source of the 195-terabyte file remains unidentified, and the full extent of actual exploitation—how many keys have already been used for unauthorized access—remains unclear. Organizations on the list will need to rotate all exposed secrets, assume that any development environment during the relevant period was compromised, and verify whether their supply chains contain the compromised packages even in newer versions.