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.
Check if your organization is exposed in this AI Supply Chain Breach :https://exposure.cloudsek.com/ai-supply-chain-incident
2,500+
companies in CloudSEK’s reconstructed
exposure dataset
434,000
CI/CD pipelines potentially exposed
40 min
approximate period the affected PyPI
packages were live
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.
| Organization / domain | Secrets | Runs | Confidence |
|---|---|---|---|
| NVIDIA Corporationnvidia.com | 153 | 176 | High |
| Amazon Web Services (AWS)amazon.com | 19 | 12 | High |
| Samsung Electronicssamsung.com | 10 | 19 | High |
| Salesforce, Inc.— | 2 | 4 | High |
| Cisco Systems, Inc.cisco.com | 327 | 1,900 | High |
| F. Hoffmann-La Roche AGroche.com | 4 | 16 | High |
| Accenture Federal Servicesaccenturefederal.com | 8 | 12 | High |
| ServiceNowservicenow.com | 44 | 162 | High |
| Siemens AGsiemens.com | 21 | 138 | High |
| S&P Globalspglobal.com | 1,218 | 1,108 | High |
| Airbus U.S. Space & Defenseairbus.com | 0 | 64 | High |
| John Deeredeere.com | 185 | 203 | High |
| Regeneron Pharmaceuticals, Inc.regeneron.com | 184 | 57 | High |
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 Reutersthomsonreuters.com | 0 | 36 | High |
| FedExfedex.com | 164 | 147 | High |
| Munich Remunichre.com | 110 | 62 | High |
| MediaTek Inc.mediatek.com | 126 | 119 | High |
| Volkswagen AGvolkswagenag.com | 0 | 2,242 | High |
| Deloittedeloitte.com | 462 | 503 | High |
| The Kroger Co.kroger.com | 95 | 35 | High |
| Siemens Energysiemens-energy.com | 0 | 36 | High |
| Thales Groupthalesgroup.com | 146 | 266 | High |
| X Corp (Twitter)twitter.com | 3,459 | 1,153 | High |
| Zscaler, Inc.zscaler.com | 65 | 304 | High |
| Epic Gamesepicgames.com | 62 | 31 | High |
| Organization / domain | Secrets | Runs | Confidence |
|---|---|---|---|
| Orange S.A.orange.com | 180 | 5,642 | High |
| HP Inc.hp.com | 1 | 18 | High |
| Philipsphilips.com | 5 | 6 | High |
| Fortum Oyjfortum.com | 823 | 455 | High |
| Vodafone Group Plcvodafone.com | 83 | 51 | High |
| Carl Zeiss AGzeiss.com | 119 | 178 | High |
| Deutsche Bahn AG, | 25 | 35 | High |
| NGINX, Inc.nginx.com | 267 | 269 | High |
| BT Groupbt.com | 216 | 325 | High |
| Liebherrliebherr.com | 98 | 20 | High |
| Krungthai Bank Public Company Limitedkrungthai.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.
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/<pid>/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
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 forroduction 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 |
| Source-control access | GitHub/GitLab tokens, SSH keys, deploy keys | Repository theft, malicious commits, secret discovery |
| Package publishing | npm, PyPI, container registry and artifact tokens | Downstream supply chain compromise |
| Kubernetes and CI/CD | Cluster tokens, runner secrets, service accounts | Workload takeover, lateral movement, service disruption |
| AI provider access | Model API keys and gateway credentials | Prompt/data exposure, model abuse, cost fraud |
| Application secrets | .env files, database URLs, SaaS keys, webhook tokens | Data theft, impersonation, operational compromise |
| Code and artifacts | 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.
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.
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-r 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.
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.
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, Confidence, and Responsible Interpretation
Strong disclosure separates observed exposure, probable compromise, and confirmed malicious activity.
CloudSEK research inputs
- 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.
CloudSEK AIVigil- AI Attack Surface Monitoring
Primary references
1. LiteLLM , Security Update: Suspected Supply Chain Incident (24 March 2026)
2. FBI , Cyber Criminal Group TeamPCP, FLASH-20260702-01 (2 July 2026)
3. Unit 42 , TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure (31 March 2026)
4. Sophos , Vect and TeamPCP Partner for Ransomware Campaigns (2 July 2026)
5. CloudSEK , Introducing AIVigil: AI Attack Surface Monitoring
6. CloudSEK , What Is AI Attack Surface Monitoring?
