LiteLLM Supply Chain Attack Exposes Credentials Belonging to Thousands of Organizations

Malicious Versions Published on PyPI

A supply chain attack targeting LiteLLM, an open-source gateway for AI-powered applications, allegedly led to the distribution of the SANDCLOCK backdoor and the exposure of numerous operational credentials.

The operation has been attributed to TeamPCP, which reportedly obtained the project administrators’ credentials. The attackers then allegedly uploaded the compromised versions 1.82.7 and 1.82.8 to PyPI, publishing them around March 2026.

The exposure window may therefore have lasted for at least several months. Some organizations may not yet have detected the installation of the tampered component or the subsequent use of stolen credentials.

LiteLLM is used as a library and integration layer to route requests to more than one hundred large language model providers. Supported environments include OpenAI, Anthropic, Google Gemini, and local models managed through Ollama.

Compromising a component installed in automated pipelines can significantly expand the attack surface. Attackers do not need to target every company directly: inserting malicious code into a component shared by numerous applications and development processes may be enough.

SANDCLOCK and the Potential Credential Path

The available brief identifies SANDCLOCK as a backdoor but does not disclose its internal operation or specify which data it collects directly or which infrastructure it sends that data to.

The most significant factor is LiteLLM’s execution context. The software may run in development environments, CI/CD systems, automation tools, and services that must authenticate to cloud providers or AI APIs.

Under these conditions, a tampered package may access environment variables, configuration files, and secrets used by pipelines. Potentially exposed credentials include:

• keys for AWS, GCP, and Firebase infrastructure;
• tokens for registries such as Amazon ECR and JFrog;
• GitHub personal access tokens, or PATs;
• private keys for GitHub Apps;
• SSH credentials;
• Kubernetes cluster secrets;
• signing passwords;
• API keys for AI services, including OpenAI and Anthropic keys.

This type of access may allow attackers to read or modify repositories, tamper with build and deployment pipelines, access image or package registries, and interfere with cloud infrastructure. Where elevated privileges are available, the risk may extend to Kubernetes clusters and the services deployed in those environments.

It is not known whether every collected credential was used for subsequent activity. However, the mere possibility of exposure requires secrets to be revoked and replaced; organizations should not assume that a key was left unused.

Scope of the Exposure

Resecurity analyzed a 150 GB archive attributed to TeamPCP’s activity. The owners.txt and repos.txt manifests reportedly listed 898 distinct GitHub owners, including organizations and accounts, across 2,038 repositories.

The compromise is fragmented: 631 owners reportedly had only one repository listed. The entity with the largest number of affected repositories was allegedly Cencosud-Cencommerce, with 64.

The names included Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me, and 1inch.

Resecurity cataloged 2,146 records based on the names of the keys. The values were reportedly not examined beyond structural masking; the figure therefore represents the items identified in the archive, not necessarily credentials that remained valid or were successfully used.

According to the reconstruction, the incident affected more than 2,500 organizations and hundreds of thousands of CI/CD environments. The difference between the total number of organizations and the number of listed GitHub owners may be attributable to the structure of the analyzed data and the cataloging criteria.

Technology, Finance, and Healthcare Among the Exposed Sectors

The most represented sector is technology and software, where the use of open-source tools and automated pipelines is particularly widespread.

It is followed by banking, finance, and insurance, as well as healthcare, pharmaceuticals, and medtech. The presence of regulated organizations increases the significance of the incident: a compromise may affect operational continuity, data protection, and access-management obligations.

Other identified sectors include:

1. retail and e-commerce;
2. media, gaming, and adtech;
3. manufacturing and industry;
4. professional services;
5. cybersecurity;
6. cryptocurrency;
7. government.

The actual risk depends on the privileges assigned to LiteLLM and the pipelines in which the package was installed. An isolated test environment does not have the same impact as a CI/CD runner authorized to publish images, update infrastructure, or deploy applications to production.

The attack may also increase the time required to detect the incident. The malware may have executed in numerous environments with different configurations, making event correlation more difficult and increasing both MTTD, mean time to detect, and MTTR, mean time to respond and recover.

Checks to Launch Immediately

Organizations that installed LiteLLM should check for versions 1.82.7 and 1.82.8 across projects, container images, package-manager caches, and CI/CD runners. They should also check for indirect installations through dependencies or preconfigured images.

If either version is present—or if there is any uncertainty—the response should include:

• revoking and regenerating private keys for GitHub Apps;
• replacing GitHub PATs and tokens;
• rotating AWS, GCP, and Firebase credentials;
• revoking ECR and JFrog tokens;
• replacing SSH keys;
• changing signing passwords;
• regenerating API keys for AI providers;
• invalidating active sessions.

Rotation should begin with accounts holding administrative privileges and secrets used in build and deployment processes. New values should not be added to pipelines that have not yet been verified.

The next step is to analyze GitHub logs, CI/CD runners, registries, cloud providers, and Kubernetes clusters. Organizations should look for anomalous access, token creation, workflow changes, new SSH keys, unexpected package or image publications, and deployments that cannot be attributed to authorized operators.

There is no available indication that the incident has been added to CISA’s KEV catalog or that a related mitigation deadline has been issued. The available material also does not identify an associated CVE.

Organizations that installed LiteLLM during the affected period should treat credentials present in the environment as potentially exposed, even without immediate indicators of abuse. A compromised software dependency can leave traces in downstream systems long after the malicious package was published.