AI Supply Chain Breach 2,500+ Organizations & 434,000 CI/CD Pipelines Potentially Exposed

CloudSEK analyzed a supply chain attack involving LiteLLM, estimating that more than 2,500 organizations and approximately 434,000 CI/CD pipelines were included in a dataset of potentially exposed entities following an attack campaign in March 2026. The campaign was linked to the threat actor group TeamPCP.

However, it is important to understand that these figures are based on a Reconstructed Exposure Dataset. CloudSEK emphasizes that the data should not be interpreted as evidence that every organization listed was successfully compromised or that credentials from every organization were stolen.

An organization appearing in the dataset should therefore be considered potentially exposed, and further internal investigation is required before concluding that an actual compromise occurred.

Check Whether Your Organization is Potentially Exposed

CloudSEK has made an AI Supply Chain Incident Exposure Checker available to help organizations determine whether their name appears in the exposure dataset related to this incident.

Check your organization: https://exposure.cloudsek.com/ai-supply-chain-incident

If your organization appears in the dataset, the result should be treated as a starting point for further investigation. Recommended actions include reviewing build and dependency history, identifying credentials that may have been accessible, reviewing relevant logs, and rotating credentials based on the level of risk.

How Can a Supply Chain Attack Spread to Other Systems?

CloudSEK reported that Trivy, a security scanner used upstream in the development process, was compromised by attackers. The incident involved a leaked automation token that had been rotated but not fully revoked, allowing attackers to replace code behind version tags that appeared legitimate.

The LiteLLM CI pipeline installed Trivy without sufficiently strict dependency pinning. As a result, the compromised scanner was automatically introduced into the build process, ultimately leading to the creation and publication of affected LiteLLM versions 1.82.7 and 1.82.8 on PyPI.

The affected package remained available on PyPI for an exposure window of approximately 40 minutes. However, because CI/CD environments operate through automation, scheduled jobs, dependency resolvers, build runners, developer machines, and cached layers could rapidly download and distribute the package into other environments.

This means that even though the malicious package was present in the repository for only a short period, the resulting impact may require significantly more time to investigate and remediate.

A Key Concern: The Payload Could Execute Without import LiteLLM

One of the most important technical details is that the malicious payload was delivered through a .pth file.

According to CloudSEK, this type of file can execute when the Python interpreter starts, without requiring an explicit import LiteLLM statement. This means that environments where an affected package was installed could potentially execute the malicious payload even if LiteLLM itself was never directly imported by the application.

Credentials are a Primary Target

A major risk in this incident is not only the compromised package itself, but also the data and privileges accessible to the affected CI/CD runner or environment.

CloudSEK reported that a credential stealer tracked by Google as SANDCLOCK was capable of discovering and collecting sensitive information from affected CI runners.

Potentially exposed information includes:

• AWS, Google Cloud, and Microsoft Azure cloud credentials
• GitHub/GitLab tokens, SSH keys, and deploy keys
• Kubernetes tokens and service accounts
• Environment variables, .env files, and CI/CD secrets
• Package publishing and container registry credentials
• Database, SaaS, and webhook credentials
• LLM API keys and AI gateway credentials
• Private source code, build images, and build artifacts

CloudSEK also noted that some cloud credentials could be accessed through Instance Metadata Services, while Kubernetes tokens may be available through mounted service account paths.

This means attackers may not necessarily need to exploit an additional vulnerability if the compromised process already has permission to access those credentials.

If credentials are successfully extracted from the environment, the impact may extend far beyond the original machine or package. Attackers could potentially reach cloud accounts, source code repositories, Kubernetes clusters, package registries, SaaS platforms, databases, and enterprise AI services.

Importantly, removing the malicious package from a repository does not necessarily mean the incident is over. Credentials copied during the exposure window may remain usable later unless they are properly rotated or revoked.

Why is AI Infrastructure Becoming a High-Value Target?

Modern enterprise AI infrastructure is increasingly becoming a point of convergence between data, identity, compute, and automation.

AI gateways, agent runtimes, model endpoints, vector databases, and MCP servers may connect simultaneously to model providers, cloud services, databases, plugins, and internal business applications.

In addition, agentic AI workflows may have permission to read and write data, invoke tools, or trigger business processes automatically. This can significantly expand the potential blast radius when an attacker gains access to compromised credentials.

Another challenge is that organizations may adopt AI services faster than security teams can build and maintain complete inventories. This can lead to Shadow AI, unknown AI assets, and unmanaged credentials that remain outside the visibility of security teams.

The LiteLLM incident is therefore another reminder that cybersecurity in the AI era cannot focus only on applications, endpoints, and networks. Security strategies must also cover AI dependencies, software supply chains, and the AI attack surface.

What Should Organizations Do Next?

Organizations using LiteLLM, or those with CI/CD environments potentially associated with this incident, should first determine whether their environments used LiteLLM versions 1.82.7 or 1.82.8.

They should also review runners, hosts, container images, and caches that may have been active during the relevant period.

If potential exposure is identified, organizations should consider the following actions:

• Rotate all credentials accessible to affected processes or CI/CD runners, not only LLM or LiteLLM credentials
• Review cloud, source control, package registry, and Kubernetes or cluster audit logs
• Isolate runners, hosts, images, or caches that may have been affected
• Rebuild environments from known-clean sources
• Investigate unusual token usage, logins, service account activity, or network egress
• Pin dependencies and GitHub Actions using verified hashes
• Reduce credential lifetime and scope, and consider workload identity instead of static keys
• Continuously monitor CI/CD runtime behavior and third-party AI dependencies
• Maintain a clear inventory of AI assets, AI services, and responsible owners

CloudSEK also emphasizes that organizations should not wait for evidence that production or privileged credentials have already been abused before rotating them.

The absence of suspicious activity does not prove that a credential was never copied. In many cases, the cost of rotating credentials is far lower than the potential damage caused by delayed incident containment.

Improve Visibility Across AI and Software Supply Chain Risk with CloudSEK Managed by BMSP

Cybersecurity in the AI era can no longer focus solely on systems developed internally.

Every library, package, SDK, model provider, plugin, and third-party service connected to the development and AI ecosystem can become part of an organization’s attack surface.

BMSP helps organizations improve visibility across digital and AI supply chain risks with CloudSEK solutions, enabling security teams to identify exposure across third-party dependencies, AI infrastructure, and the external attack surface.

Gain visibility into risks before they can be used as attack paths, and strengthen security across your Digital & AI Supply Chain with CloudSEK managed by BMSP.

Reference

• CloudSEK