# 2,500 Companies and 434,000 Pipelines Exposed – Largest AI Supply Chain Breach > Source: > Published: 2026-08-11 09:48:42+00:00 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026 CloudSEK’s latest research examines the LiteLLM AI supply-chain attack, which potentially exposed 2,500+ organisations and 434,000 CI/CD pipelines worldwide. The report details the risks to cloud credentials, source-code repositories, Kubernetes environments and AI infrastructure, while highlighting how compromised AI dependencies can create enterprise-wide security exposure. Get the latest industry news, threats and resources. No items found. Executive Summary In March 2026, the threat actor group Team PCP orchestrated what is believed to be the largest supply chain attack targeting AI infrastructure by compromising LiteLLM. CloudSEK Threat Intelligence was able to get access to the victim information and is disclosing the details of all the impacted victims . We are sharing this openly so that every affected organization can act proactively The threat is still live: the FBI's July 2026 FLASH advisory (FLASH-20260702-01) warns that affiliated actors are likely to weaponize the harvested credentials long after the original intrusion, which means further supply chain attacks remain a real possibility. Early awareness is the strongest defense; knowing you were impacted lets you rotate credentials, close the exposure, and harden before the next campaign hits. Attacks on AI infrastructure are on the rise and that is exactly what CloudSEK AIvigil, our AI Attack Surface Monitoring platform, is built to prevent. AIvigil continuously discovers, monitors, and secures exposed AI infrastructure, MCP servers, leaked AI credentials, vector databases, agentic workflows, and shadow AI. We combine the power of cyber threat intelligence and AI exposure to detect and prevent cyberattacks on AI infrastructure. Those exposed range from large AI companies and model providers to cybersecurity vendors, SaaS platforms, and enterprises worldwide. companies in CloudSEK's reconstructed exposure dataset 434,000 CI/CD pipelines potentially exposed 40 min approximate period the affected PyPI packages were live VICTIM EXPOSURE DATA Selected High-Confidence Organizations in the Exposure Dataset The records below are the leading organization-level matches supplied for this report. High confidence refers to the strength of the exposure match,not proof of successful compromise or attacker use. “Secrets” and “Runs” are reproduced as aggregate counts from the supplied dataset. Domains are shown only where provided. No secret values, credentials, internal paths, or personal information are included. Selected High-Confidence Organizations — continued Organization / domain Secrets Runs Confidence Robert Bosch GmbH — 1 1 High London Stock Exchange Group (LSEG) lseg.com 48 241 High Thomson Reuters thomsonreuters.com 0 36 High FedEx fedex.com 164 147 High Munich Re munichre.com 110 62 High MediaTek Inc. mediatek.com 126 119 High Volkswagen AG volkswagenag.com 0 2,242 High Deloitte deloitte.com 462 503 High The Kroger Co. kroger.com 95 35 High Siemens Energy siemens-energy.com 0 36 High Thales Group thalesgroup.com 146 266 High X Corp (Twitter) twitter.com 3,459 1,153 High Zscaler, Inc. zscaler.com 65 304 High Epic Games epicgames.com 62 31 High Selected High-Confidence Organizations , continued Organization / domain Secrets Runs Confidence Orange S.A. orange.com 180 5,642 High HP Inc. hp.com 1 18 High Philips philips.com 5 6 High Fortum Oyj fortum.com 823 455 High Vodafone Group Plc vodafone.com 83 51 High Carl Zeiss AG zeiss.com 119 178 High Deutsche Bahn AG , 25 35 High NGINX, Inc. nginx.com 267 269 High BT Group bt.com 216 325 High Liebherr liebherr.com 98 20 High Krungthai Bank Public Company Limited krungthai.com 614 604 High Roku, Inc. roku.com 61 51 High Interpretation requirement A high-confidence organization match should trigger private validation, notification, credential review, and log investigation. Public wording should remain “potentially exposed” unless malicious execution, exfiltration, unauthorized access, or downstream use has been independently verified. DATA AT RISK What matters for victims The stolen object was Cloud keys, repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables, and AI provider keys could allow attackers to move far beyond the affected package. Removal does not end the incident. A package can disappear in minutes while copied credentials remain usable for weeks or months unless they are rotated and downstream activity is investigated. Automated pipelines amplify a brief compromise. CI/CD systems install dependencies at machine speed and often run with broad privileges, making a short publication window operationally significant. AI infrastructure is becoming a strategic target. Gateways, agents, vector stores, model endpoints, and MCP servers sit between sensitive data and systems capable of taking action. Actor context is secondary. Public reporting attributes the campaign to Team PCP; this report limits actor discussion to what defenders need for attribution and response. Important interpretation The 2,500+ company and 434,000 pipeline figures describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised or that every credential was stolen. The Scale of Exposure What was taken On every compromised CI runner, TeamPCP's stealer (tracked by Google as SANDCLOCK) escalated to root and swept: SSH keys AWS, GCP, and Azure credentials Kubernetes tokens .env files and CI/CD secrets — including the values GitHub Actions tries to mask, scraped directly from /proc//mem For AI builds specifically: LLM API keys and gateway configuration — the credentials to an organization's entire AI stack Cloud keys were read straight from the instance metadata service (IMDS) and Kubernetes tokens from mounted service-account paths , no exploit needed, just the access each runner already carried. The collected data was then sealed with AES-256 under a hard-coded RSA-4096 key, so even intercepted traffic stayed unreadable without the actor's private key The loot was encrypted and shipped to a typosquatted domain. Where exfiltration failed, the malware created a public repository inside the victim's own GitHub account and uploaded the stolen data there as a release asset , meaning some organizations were leaking their own secrets into public view without knowing it VICTIM EXPOSURE The Exposure: Organizations, Pipelines, and Downstream Systems How exposure can become business impact 1. Affected artifact — A compromised package or dependency enters a build or developer environment. 2. Secret access — The process reads credentials, tokens, keys, configuration, and runtime data available to that host. 3. Privilege expansion — Stolen access reaches repositories, registries, clusters, cloud accounts, SaaS tenants, or AI providers. 4. Downstream loss — Attackers can steal code and data, publish poisoned packages, persist, disrupt services, or extort the victim. What victim-level disclosure should contain Field Why it matters Organization and affected domain/project Resolves the exposure to the correct security owner and avoids ambiguous naming. Observed pipeline or dependency evidence Separates direct evidence from inference and supports reproducible validation. Credential classes potentially accessible Determines which keys, tokens, service accounts, and sessions must be rotated. Exposure window and last-known activity Defines the log-search period and the minimum investigation scope. Notification and remediation status Turns disclosure into measurable risk reduction rather than a static list. What Was at Risk Inside the Exposed Environments The value of the breach lies in what the affected process could read, not merely in the package name. LiteLLM commonly operates close to model providers, application services, and deployment systems. In CI/CD and developer environments, the same host may also hold credentials for source control, cloud infrastructure, registries, containers, and production services. The categories below are potential exposure classes when present on an affected system. Exposure class Examples Potential consequence Cloud credentials AWS, GCP, Azure keys and metadata-service tokens Account takeover, data access, compute abuse, persistence Private repositories, builds, images, model assets IP theft, backdoors, release tampering Why credential rotation must be broad Rotating only the LiteLLM or model-provider key is insufficient. Any credential readable by the affected process, present in process memory, injected into the job, stored on disk, or retrievable through an instance metadata service should be treated as potentially exposed until validated. ATTACK PATH From a Trusted Package to Enterprise Access The March incident illustrates how an AI component can become an entry point into the wider software and cloud estate. 1. Upstream compromise: The release process's trusted security scanner (Trivy) was taken over. A leaked automation token , rotated but not fully revoked , left an approximately 20-day window in which the attacker force-pushed malicious code over the scanner's published version tags, so downstream builds pulling those tags received poisoned code that still looked legitimate. 2. Poisoned LiteLLM release: Versions 1.82.7 and 1.82.8 are published to PyPI during a short exposure window. 3. Automatic execution: A malicious .pth file runs when Python starts,no explicit LiteLLM import is required. Because a .pth file executes at interpreter startup rather than on import, the payload ran wherever the package was merely installed , sidestepping the --ignore-scripts protection teams rely on to keep installs safe. 4. Secret collection: Credentials and environment data available to the process can be harvested. 5. Downstream access: Repositories, cloud accounts, clusters, registries, SaaS, and AI services become reachable. 6. Persistence and reuse: Stolen access can be sold, reused, or weaponized after the malicious package is removed. How the poison reached LiteLLM LiteLLM was never attacked directly. Its CI pipeline installed the Trivy scanner unpinned from the system package manager (apt), so the compromised scanner flowed into the build automatically, and that build produced and published the malicious 1.82.7 and 1.82.8 releases to PyPI. Trivy, then the build system, then the LiteLLM release: one un-revoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure. A 40-minute package window can create a months-long incident Automated build systems compress time. Once a malicious artifact reaches a registry, scheduled jobs, dependency resolvers, ephemeral runners, developer laptops, and cached layers can copy it rapidly. The forensic and credential-rotation window therefore extends beyond package removal. AI INFRASTRUCTURE RISK Why the Next Supply Chain Wave Will Target AI Infrastructure CloudSEK assessment: AI systems are becoming high-value junctions between data, identity, compute, and autonomous action. In the industrial age, rail junctions became strategic targets because many supply routes met at one point. AI gateways, agent runtimes, MCP servers, and vector stores are becoming the junctions of digital operations. Privileged position. AI gateways and agent runtimes often hold credentials for models, databases, plugins, cloud services, and internal tools. Wide dependency graph. Modern AI stacks combine open-source packages, hosted models, SDKs, extensions, connectors, vector databases, and third parties. Autonomous execution. Agentic workflows can read, write, call tools, and trigger business processes, increasing the blast radius of stolen access. Rapid and shadow adoption. Teams deploy AI services faster than central security inventories are updated, leaving unknown assets and unmanaged credentials. High-value data. Prompts, retrieval stores, training data, model outputs, and connected business systems concentrate sensitive information. Traditional visibility gaps. Conventional attack surface tools see endpoints and ports but often miss model, agent, MCP, prompt, and AI workflow context. The lesson of LiteLLM The incident was not only a software supply chain breach that happened to involve an AI product. It demonstrated that compromising an AI control point can expose the identities and systems around it. Future attacks are likely to target the AI layer precisely because it is connected to everything else. VICTIM RESPONSE Immediate Actions for Potentially Exposed Organizations Response should assume credential exposure first, then use evidence to reduce the scope. 0–24 hours 24–72 hours Ongoing controls Identify use of LiteLLM 1.82.7/1.82.8 and affected build windows. Isolate affected runners, hosts, images, and caches. Rotate every credential accessible to the affected process, including cloud, repository, registry, Kubernetes, SaaS, database, and AI keys. Rebuild affected environments from known-clean sources. Hunt for unexpected repositories such as tpcp-docs/docs-tpcp, suspicious egress, unauthorized tokens, and new service accounts. Review cloud, source-control, package registry, and cluster audit logs. Pin dependencies and GitHub Actions to verified hashes. Shorten credential lifetime and scope; prefer workload identity over static keys. Monitor CI/CD runtime behavior and third-party AI dependencies continuously. Inventory AI assets and owners. Investigation questions that determine real victim impact Was an affected artifact downloaded, cached, executed, or merely referenced? Which secrets were present in environment variables, process memory, files, metadata services, or injected job contexts? Did any token show use from an unusual IP, device, geography, runner, or user agent after the exposure window? Could stolen publishing credentials have created a second-generation supply chain compromise? Did the affected AI gateway connect to sensitive prompts, vector stores, agents, internal tools, or customer data? Do not wait for proof before rotating high-value secrets A lack of obvious malicious activity is not evidence that a credential was not copied. For credentials with production reach, the cost of rotation is usually lower than the cost of delayed containment. CLOUDSEK AIVIGIL From Incident Response to Continuous AI Exposure Management CloudSEK AIVigil is built to discover and monitor the AI attack surface and supply chain attacks before exposed infrastructure becomes an attack path. AIVigil continuously discovers, monitors, and secures exposed AI infrastructure, MCP servers, leaked AI credentials, vector databases, agentic workflows, and shadow AI. It combines CloudSEK's cyber threat intelligence with AI exposure monitoring so security teams can connect an external signal to the AI asset, credential, dependency, and business system at risk. Security blind spot How AIVigil addresses it Unknown AI assets Continuous outside-in discovery and AI Bill of Materials (AI-BOM) Exposed AI services Monitoring of model endpoints, gateways, vector databases, GPU infrastructure, and cloud AI misconfigurations Leaked AI credentials Threat intelligence correlation across credential leaks, repositories, malware logs, and external sources MCP and agentic risk Assessment of MCP servers, tool access, agent permissions, and workflow exposure Shadow AI Discovery of unmanaged AI applications and services operating outside approved inventory Prioritization gap Risk scoring based on authentication, reachability, agent agency, blast radius, and live threat signals The continuous loop 1. Discover: Find AI assets and shadow AI. 2. Scan: Assess exposures and attack paths. 3. Triage: Correlate with live threat intelligence. 4. Report: Drive ownership and remediation. The objective Move from learning about an AI infrastructure breach after credentials are stolen to continuously knowing which AI assets exist, what they expose, and which attack paths require action now. METHODOLOGY AND SCOPE Methodology, Confidence, and Responsible Interpretation CloudSEK’s Threat Intelligence team obtained the exposure data through its intelligence sources, including records relating to organizations, CI/CD pipelines, and credential/token exposures associated with the March 2026 supply-chain cascade involving compromised Trivy, Checkmarx KICS, and LiteLLM builds The exposed AI and cloud assets those credentials reach , model endpoints, gateways, vector databases, GPU infrastructure, cloud accounts, and MCP/agentic workflows The three weaponized tool vectors that produced the exposure: Trivy, Checkmarx KICS, and LiteLLM Public advisories confirming the campaign and affected tooling: FBI FLASH, Aqua Security, Checkmarx, LiteLLM/BerriAI, Unit 42, and Sophos Recommended confidence labels for the victim dataset Label Meaning Recommended wording Exposed Evidence links the organization or pipeline to an affected artifact or exposure path. Potentially exposed; validation required. Probable compromise Execution or credential-access evidence exists, but attacker use is not confirmed. Likely affected; containment and investigation required. Confirmed compromise Malicious execution, exfiltration, unauthorized access, or downstream use is verified. Confirmed victim; incident response active. Attribution in one paragraph Public reporting attributes the broader campaign to the financially motivated cluster Team PCP. The actor compromised trusted security and developer tooling and used credential-stealing payloads to reach cloud and CI/CD environments. The identity, internal disputes, forum affiliations, and leadership history of the group are not required to understand victim exposure and are intentionally excluded from the main narrative. SOURCES AND CONCLUSION CloudSEK AIVigil- AI Attack Surface Monitoring Attacks on AI infrastructure are on the rise and that is exactly what CloudSEK AIvigil, our AI Attack Surface Monitoring platform, is built to prevent. AIvigil continuously discovers, monitors, and secures exposed AI infrastructure, MCP servers, leaked AI credentials, vector databases, agentic workflows, and shadow AI. We combine the power of cyber threat intelligence and AI exposure to detect and prevent cyberattacks on AI infrastructure.