NEW DELHI: A major software supply-chain attack linked to the compromise of the popular LiteLLM project exposed credentials and configuration data associated with hundreds of organisations and more than 2,000 software repositories, according to new research by cybersecurity company Resecurity.
In a report published on August 14, Resecurity said it had obtained and analysed a 152.5 GiB archive containing 415,427 files allegedly collected from compromised software development environments during the March 2026 attack. The victim records covered 898 GitHub owners and 2,038 repositories, the company said.
The affected repository owners listed in the dataset include names associated with Microsoft, Microsoft Azure, IBM, NVIDIA, FedEx, PayPal’s Zettle, Deloitte, Bosch, S&P Global, Elevance Health, ID.me and several other companies. Resecurity cautioned that appearing in the leaked manifests does not, by itself, show how deeply each organisation was compromised and said affected entities should conduct their own forensic checks.
The findings offer a closer look at the potential scale of a security incident that began not with LiteLLM itself, but further up the software supply chain.
Read Full Report Here: The LiteLLM Supply-Chain Attack — TeamPCP “SANDCLOCK” CI/CD Credential-Harvesting Campaign via a Backdoored Trivy GitHub Action
Attackers Targeted a Tool Used to Check Software for Security Flaws
The attack began after credentials linked to Trivy, an open-source security scanner developed by Aqua Security, were compromised.
Trivy is widely used by developers and companies to automatically scan software for vulnerabilities before it is deployed. One way organisations use it is through GitHub Actions, which automatically perform tasks such as testing, scanning and publishing software whenever developers make changes to code.
According to a GitHub security advisory, attackers on March 19 used compromised credentials to publish a malicious Trivy release and alter dozens of version tags associated with the aquasecurity/trivy-action project so that they pointed to credential-stealing code.
That meant companies whose automated development systems trusted and downloaded the affected Trivy components could unknowingly execute the attackers’ code inside their own software-building infrastructure.
Resecurity attributes the operation to a threat group known as TeamPCP, which it says deployed a credential-stealing tool called SANDCLOCK.
ALSO READ: BTMob Network Uses More Than 1,400 Live Servers to Power Android Malware
How LiteLLM Became Part of the Attack
LiteLLM is an open-source software project that helps developers connect applications to multiple artificial intelligence models and services through a common interface.
According to Resecurity’s reconstruction of the incident, LiteLLM’s automated development environment used the compromised Trivy component. Attackers were then able to obtain credentials used to publish LiteLLM packages to PyPI, a widely used repository for Python software.
Malicious LiteLLM packages subsequently appeared on PyPI on March 24.
LiteLLM’s team later said the compromised versions 1.82.7 and 1.82.8 had been removed, maintainer credentials had been rotated and releases were temporarily paused while the project reviewed its software supply chain.
Independent reports posted to LiteLLM’s GitHub repository found credential-stealing code inside version 1.82.8 that could execute automatically when Python started, potentially allowing it to collect sensitive information from machines where the package was installed.
In simple terms, attackers first compromised software used to check other software for security problems, then used access gained from that breach to compromise another trusted software package.
That is what makes supply-chain attacks particularly dangerous. Instead of attacking thousands of companies one by one, criminals can compromise a trusted piece of software that many organisations already use.
Credentials Taken Directly From Development Systems
Resecurity said the stolen material appeared to have been collected directly from computers running automated software-development jobs rather than intercepted while travelling across the internet.
The data included GitHub access tokens, cloud credentials, private keys, SSH credentials, container registry tokens and passwords used in development and software-signing processes.
In a sample of 1,073 files examined by Resecurity, researchers identified 2,146 secret records. GitHub Actions tokens appeared in roughly 98% of the sampled files, according to the report.
Those tokens can give automated systems temporary permission to modify code repositories, publish software or interact with other development resources.
Other credentials identified in the sample were linked to services including Amazon Web Services, Google Cloud, Firebase, GitHub applications and software registries such as Amazon ECR and JFrog.
For ordinary users, these credentials can be thought of as digital keys used by companies’ internal systems. If attackers obtain the right keys, they may be able to access cloud infrastructure, alter software or impersonate trusted automated systems.
Why the Breach Could Have Consequences Beyond LiteLLM
The immediate theft of credentials is only one part of the risk.
Resecurity warned that stolen development and publishing credentials could potentially be used to compromise additional software projects. An attacker who gains permission to modify a trusted repository or publish software packages could insert malicious code into products downloaded by other organisations.
That creates the possibility of what researchers describe as a second-order supply-chain attack, where one compromised company or project becomes the route into many more victims.
The LiteLLM incident itself demonstrates how such a chain can develop.
The attackers first compromised Trivy. That compromise affected software-development systems that trusted Trivy. Credentials obtained from one of those environments were then used to tamper with LiteLLM packages, potentially exposing another group of downstream users.
Resecurity classified the incident as a high-to-critical severity supply-chain compromise because the stolen credentials could potentially enable attackers to modify source code, publish malicious software, access cloud accounts or interfere with software-development pipelines.
Major Companies Appear in the Victim Data
Resecurity said the victim manifests associated with the archive contained 898 distinct GitHub owners.
Among the notable names listed were:
- Microsoft and Microsoft Azure
- IBM
- NVIDIA
- FedEx
- John Deere
- PayPal’s Zettle
- Deloitte
- Bosch
- S&P Global
- Elevance Health
- Kroger-linked data analytics company 84.51°
- Adeo, the parent group associated with Leroy Merlin
- Kärcher
- Dräger
- ID.me
- Cencosud
- cryptocurrency platform 1inch
The report also said identifiers associated with a US AWS GovCloud environment appeared in the recovered sample.
However, the presence of an organisation’s repository or account name in the dataset should not automatically be interpreted as evidence that its wider corporate network was breached. Resecurity itself notes that the records show repositories implicated in the harvesting activity, while the actual impact on individual organisations requires further investigation.
What Organisations Should Do
Resecurity has urged organisations that may have been exposed to assume that credentials available to affected development systems could have been stolen.
The company recommends replacing persistent credentials such as cloud access keys, GitHub application keys, personal access tokens, SSH keys and software-signing passwords.
Security teams have also been advised to examine activity between March 19 and March 24, including unusual changes to repositories, unexpected software releases, package publications and suspicious access to cloud services.
Organisations should also review how much access automated development systems receive.
Restricting permissions, using short-lived credentials, locking software dependencies to verified versions and monitoring automated build systems can reduce the damage when a trusted software component is compromised.
A Warning About Trust in the Software Supply Chain
The incident highlights an increasingly difficult problem for organisations: modern applications are rarely built entirely from software written inside one company.
Developers routinely depend on open-source libraries, automated security scanners, cloud services and third-party tools. A weakness in any one of those components can potentially create a path into organisations further down the chain.
In this case, the initial target was itself a cybersecurity tool.
The compromise then moved through automated software-development infrastructure before reaching LiteLLM, a widely used project in the rapidly growing AI ecosystem.
For security teams, the lesson is increasingly clear: a trusted software supplier or security tool cannot automatically be treated as trusted forever. The integrity of software dependencies, automated pipelines and the credentials behind them has become a critical part of enterprise security.
The March attack may have lasted only days, but the credentials and access it exposed could have consequences long after the malicious software was removed.
