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
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.
Organization / domain
Secrets
Runs
Confidence
NVIDIA Corporation
nvidia.com
153
176
High
Amazon Web Services (AWS)
19
12
High
Samsung Electronics
samsung.com
10
19
High
Salesforce, Inc.
—
2
4
High
Cisco Systems, Inc.
cisco.com
327
1,900
High
F. Hoffmann-La Roche AG
roche.com
4
16
High
Accenture Federal Services
accenturefederal.com
8
12
High
ServiceNow
servicenow.com
44
162
High
Siemens AG
siemens.com
21
138
High
S&P Global
spglobal.com
1,218
1,108
High
Airbus U.S. Space & Defense
airbus.com
0
64
High
John Deere
deere.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 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 victimsThe 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 ExposureWhat was taken
On every compromised CI runner, TeamPCP’s stealer (tracked by Google as SANDCLOCK) escalated to root and swept:
SSH keysAWS, GCP, and Azure credentialsKubernetes tokens.env files and CI/CD secrets — including the values GitHub Actions tries to mask, scraped directly from /proc//memFor 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 SystemsHow 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
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.
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 impactWas 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
Strong disclosure separates observed exposure, probable compromise, and confirmed malicious activity.
CloudSEK research inputsCloudSEK’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 buildsThe exposed AI and cloud assets those credentials reach , model endpoints, gateways, vector databases, GPU infrastructure, cloud accounts, and MCP/agentic workflowsThe three weaponized tool vectors that produced the exposure: Trivy, Checkmarx KICS, and LiteLLMPublic advisories confirming the campaign and affected tooling: FBI FLASH, Aqua Security, Checkmarx, LiteLLM/BerriAI, Unit 42, and SophosRecommended 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.
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