Terabytes of credentials belonging to some of the world’s most sensitive organizations—including Microsoft, Amazon, Cisco, Samsung, and Salesforce—have been exposed in a devastating supply-chain attack on LiteLLM, an open-source tool widely used to streamline AI-driven software development. Security firms CloudSEK and Hudson Rock revealed on Tuesday and Wednesday that the breach compromised more than 2,500 organizations, leaking cloud keys, repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables, and AI provider keys. The attack exploited a brief 40-minute window in March during which victims downloaded compromised versions of LiteLLM from the official Python Package Index (PyPI) repository, and the stolen data was later discovered inside a massive 195-terabyte file.
The Anatomy of the Attack: LiteLLM and the PyPI Compromise
LiteLLM is an open-source library that simplifies the integration of large language models (LLMs) from multiple providers into a single interface. Developers use it to quickly build AI features without managing separate APIs for each model provider. Its popularity made it a high-value target. The compromise did not originate with LiteLLM itself but cascaded from an earlier supply-chain attack that had already infected the widely used vulnerability scanner Trivy.
The 40-Minute Window
According to the security reports, attackers managed to upload malicious versions of LiteLLM to PyPI, the official Python package ecosystem, and keep them available for download for just 40 minutes. During that brief exposure, any developer or organization that ran pip install litellmcodecodecodecodecode (or updated to the affected version) would have pulled down code that exfiltrated sensitive credentials from the host environment. The attackers collected credentials from cloud environments, CI/CD pipelines, code repositories, and AI service provider accounts. The speed and precision of the attack suggest that the threat actors had prepared the malicious payloads in advance and timed the upload to coincide with periods of high developer activity.
A Cascade of Compromises: Trivy, KICS, and Telnyx
The LiteLLM breach was not an isolated incident. It was part of a broader supply-chain campaign that had already compromised Trivy, a vulnerability scanner used by thousands of enterprises for container and infrastructure security. The same malicious infrastructure also infected KICS, an open-source infrastructure-as-code scanning tool, and the Telnyx Python SDK, a library for telecom API integrations. Each of these packages is widely adopted in DevOps and cloud-native environments, meaning the attack surface extended far beyond AI development teams. The attackers leveraged the initial foothold in Trivy to inject code into subsequent packages, including LiteLLM, creating a multi-stage infection chain that bypassed standard security checks.
Who Is TeamPCP? The Teenage Threat Behind the Breach
A group calling itself TeamPCP took credit for the attack, and independent security researchers have largely corroborated the claim. TeamPCP is described as a ramshackle but extremely capable gang made up largely of teenagers. Their technical sophistication, particularly in exploiting open-source supply chains, has surprised many in the security community. Kevin Beaumont, a respected independent security researcher, confirmed the stolen data is legitimate. He stated that the archive contains a significant volume of sensitive content from multiple victim organizations, calling it “a massive supply chain breach due to poor AI securityaaa—not because AI is the threat, but teens can run circles around orgs obsessed with rushing out AI and poor DevOps security.”
The group’s ability to execute a coordinated attack across multiple popular open-source projects demonstrates that age and organizational structure are not reliable predictors of threat capability. For enterprise security teams, the TeamPCP case underscores a growing reality: low-barrier entry into cybercrime, combined with widespread access to automated attack tools and compromised infrastructure, allows even small, loosely organized groups to cause damage on a scale once reserved for state-sponsored actors.
What Was Exposed: The Full Scope of Credential Leakage
The 195-terabyte file analyzed by Hudson Rock contained a staggering variety of credential types. CloudSEK enumerated the following categories of leaked secrets:
- Cloud keys: Access keys and secret keys for AWS, Azure, and Google Cloud, giving attackers the ability to read, modify, or delete cloud resources.
- Repository tokens: Authentication tokens for GitHub, GitLab, and Bitbucket, potentially allowing code modification, pipeline execution, or data theft.
- SSH keys: Private keys used for secure shell access to servers, enabling remote command execution and lateral movement within networks.
- Kubernetes secrets: Credentials and configuration data stored in Kubernetes clusters, exposing container orchestration environments.
- Package publishing credentials: Tokens for PyPI, npm, and other package registries, which could be used to push malicious updates to other software.
- Environment variables: Configuration values often containing database passwords, API keys, and other secrets hardcoded in development environments.
- AI provider keys: API keys for OpenAI, Anthropic, and other LLM services, potentially allowing attackers to use AI services at victims’ expense or access sensitive model data.
The exposure of AI provider keys is particularly concerning because many enterprises rely on these APIs for customer-facing applications. An attacker with a valid OpenAI API key could not only incur massive costs but also access the model usage history and any data sent to the API—potentially exposing proprietary business logic or customer information.
How Did This Happen? The Mechanics of a PyPI Supply-Chain Attack
PyPI, like other open-source package repositories, relies on a trust model where package maintainers are responsible for the security of their uploads. Attackers can compromise a maintainer’s account through phishing, credential theft, or session hijacking, and then upload malicious versions of legitimate packages. In the LiteLLM case, the attackers used a compromise of Trivy—which had already been infected—to gain the credentials or access needed to push malicious LiteLLM updates. The attack chain is typical of software supply-chain attacks: each compromised package becomes a stepping stone to the next.
The 40-minute window of LiteLLM’s exposure is notable because it suggests the attackers deliberately limited the time their malicious package was available to reduce the chance of detection. Automated scanning tools that continuously monitor PyPI for suspicious uploads might have flagged the package if it remained online longer. By keeping the window short, the attackers ensured that only those who downloaded during that precise period were affected, making incident response more difficult because victims may not realize they were compromised until weeks later.
Implications for the AI Industry and Open Source Security
The LiteLLM breach is one of the most significant supply-chain attacks targeting the AI industry to date. It highlights a critical vulnerability: the rapid adoption of AI development tools has outpaced the security practices of both the open-source community and the enterprises that depend on it. Many organizations rush to integrate AI capabilities without fully vetting the supply chain of the tools they use. LiteLLM itself is a relatively young project, and its maintainers may not have had the security infrastructure of larger projects. Attackers recognized this asymmetry and exploited it.
For enterprises, the breach serves as a stark reminder that any open-source dependency—no matter how popular or well-maintained—can become a vector for credential theft. The affected companies, which include some of the largest technology firms in the world, now face the urgent task of rotating every exposed credential, auditing access logs for unauthorized activity, and reassessing their reliance on open-source AI libraries. The scale of the cleanup is enormous: with credentials from tens of thousands of pipelines and cloud environments potentially compromised, the operational burden on security teams will be immense.
Furthermore, the incident raises questions about the security of PyPI and similar registries. While package repositories have implemented measures such as two-factor authentication and malware scanning, determined attackers continue to find ways around them. The use of legitimate maintainer accounts—compromised through previous supply-chain attacks—makes detection especially challenging. Until the open-source ecosystem adopts more robust identity verification and code signing, attacks like this will remain a persistent threat.
Questions This Breach Raises for Enterprise Security Teams
How did the LiteLLM breach expose credentials from Microsoft, Amazon, and other major companies?
The breach occurred when developers at those organizations downloaded a compromised version of LiteLLM from PyPI during a 40-minute window in March. The malicious code exfiltrated credentials stored on the developers’ machines or in their CI/CD environments, including cloud API keys, repository tokens, and AI provider secrets. Because LiteLLM is used in AI development pipelines that often have broad access to cloud infrastructure, the attackers obtained credentials that allowed them to impersonate legitimate users across multiple services.
The Role of Trivy and Wider Infection
The LiteLLM attack was possible only because the threat actors first compromised Trivy, a vulnerability scanner that many DevOps pipelines run automatically. By gaining access to Trivy’s update mechanism, the attackers could inject malicious code into subsequent package updates. They then used that same infrastructure to compromise KICS and the Telnyx Python SDK, expanding their reach. For security teams, this means that even tools designed to improve security—like vulnerability scanners—can themselves become attack vectors. The incident underscores the need to treat all software dependencies, including security tools, as potential risk factors.
For organizations that use any of the affected packages, the immediate remediation steps are clear: identify all instances where the compromised versions were downloaded, rotate every credential that could have been exposed, enable comprehensive logging and monitoring for unusual access patterns, and review all dependencies for signs of tampering. Longer term, enterprises should consider implementing stricter controls on package downloads, such as using private mirrors, vetting packages through automated security scanning, and requiring code reviews for dependency updates.
The LiteLLM breach is not a one-off event but a symptom of deeper systemic issues in the open-source software supply chain. As AI adoption accelerates, attackers will continue to target the tools and libraries that developers depend on most. The key takeaway for organizations is not to fear AI itself, but to recognize that the rush to deploy AI features without corresponding investment in supply-chain security creates exactly the kind of opening that groups like TeamPCP can exploit with devastating effect. The only effective defense is a fundamental shift in how enterprises manage software dependencies: from a posture of implicit trust to one of continuous verification, with rigorous credential hygiene and fast incident response capabilities. Until that shift occurs, the 40-minute window that exposed terabytes of secrets will be remembered as a warning, not an anomaly.
