Voltar
Inteligência do adversário
Tabela de conteúdo
Nenhum item encontrado.

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

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.

Full list is here -

Organization / domain Secrets Runs Confidence
NVIDIA Corporation nvidia.com 153 176 High
Amazon Web Services (AWS) amazon.com 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
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 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

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
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 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

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.

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

6. CloudSEK , What Is AI Attack Surface Monitoring?

Blogs relacionados