Team PCP Stole 78,330 Secrets From 2,186 Organizations. CloudSEK Just Published the List.

Team PCP does not breach companies one at a time. It compromises one trusted open source project, harvests every credential that flows through the CI/CD pipelines running that project, and uses those stolen secrets to break into the next one. In March 2026, that flywheel produced one of the largest credential exposures ever recorded: 78,330 secrets exfiltrated from the CI/CD pipelines of 2,186 organizations in five days. Researchers at CloudSEK have now published the list. The victims include publicly traded companies with a combined market capitalization above 6 trillion dollars. Most of them had no idea their build systems were leaking until the list went public.

This post breaks down who Team PCP is, what the CloudSEK data shows, why CI/CD pipelines have become the primary target of software supply chain attacks, and the layered security controls that stop this class of attack.

Who Is Team PCP?

Team PCP (also written TeamPCP) is the threat actor behind a chain of high-profile open source compromises in 2026. The group's signature is not a single piece of malware. It is a repeatable playbook: compromise a widely trusted component, plant a credential stealer, collect the secrets that CI/CD runners load into memory, and reinvest those credentials into the next compromise.

The public record is extensive. In March 2026, Team PCP injected a credential stealer into 76 of the 77 version tags of the Trivy GitHub Action, hit the Checkmarx KICS action days later with the same technique, planted a WAV steganography credential stealer in the telnyx PyPI package, and compromised LiteLLM in what CloudSEK describes as the largest supply chain attack targeting AI infrastructure to date. It is part of a broader wave that includes the Axios npm compromise and the ChainDrop worm. The StepSecurity research team discovered, or was among the first to publicly report, many of these attacks, and tracks the full wave on our Threat Intel blog.

Why Now? AI Changed Both Sides of the Equation

Because of the acceleration in AI technologies, everyone is a software engineer now. The volume of code being produced and shipped through software development pipelines has exploded, and every one of those pipelines is an attack surface.

Attackers have adopted AI just as fast. Supply chain attacks that once required nation-state-level resources and a team of security experts can now be executed by a single person with an AI coding agent. This is not speculation. Our security research team has seen the evidence directly while analyzing recent attacks: self-spreading worms that specifically target AI coding agents, malware with unmistakable signs of AI-assisted development, and attack timelines compressed from months to days. We covered this shift in depth in our 2026 mid-year update.

The Team PCP campaign is what those two curves colliding looks like in practice. One threat actor, moving at machine speed, compromised infrastructure trusted by thousands of organizations. And the target that made it all work was not production. It was CI/CD.

Inside the CloudSEK Disclosure: What the Data Shows

CloudSEK's Threat Intelligence team cataloged the exposure and published a searchable dataset so organizations can check whether they appear in it. We analyzed the dataset. Three findings stand out.

Every major CI/CD platform was hit. GitLab led.

This was not a GitHub Actions story. When you decode which system each victim organization was running, GitLab leads by a wide margin, and Azure DevOps, which is often left out of these conversations, appears in more than 230 organizations. A separate group of organizations leaked private keys directly from hosts and mail servers rather than from a pipeline at all.

The lesson is that this is a CI/CD problem, not a single vendor problem. The attack worked the same way on every platform, because every platform shares the same weaknesses: secrets flow into runners as environment variables that any step can read, runners ship with open outbound network access, and pipelines trust dependencies by mutable references that an attacker can silently repoint.

What Team PCP walked away with

The credential types show how far an attacker can move after the exfiltration. Nearly a thousand organizations leaked session tokens. Hundreds leaked cloud keys and source control credentials. A single one of these is often enough to move from a build runner into production, or into the next open source project.

The AI supply chain angle is real

157 organizations leaked OpenAI API keys through their pipelines. The LiteLLM compromise sat at the center of the campaign, and CloudSEK frames the entire incident as an AI supply chain event. The AI stack is being built on the same pipelines that are leaking, which is exactly why this campaign scaled the way it did.

Why Are Attackers Targeting CI/CD Pipelines?

Attackers have shifted left. Production environments have absorbed a decade of security investment: hardened perimeters, EDR on every host, tight IAM, continuous monitoring. The development and delivery pipeline got none of that. Yet CI/CD runners hold credentials that are typically more privileged than anything a phished laptop can reach: cloud deployment keys, signing keys, registry publish tokens, and access tokens for every repository in the organization.

Team PCP realized what most enterprises have not: it is far easier to steal elevated credentials from a CI/CD runner than to breach production directly. Most enterprises have zero security controls implemented for CI/CD. No runtime monitoring. No network egress restrictions. No governance over which open source packages and actions execute with secrets in scope.

Treating CI/CD like production means applying the same categories of control you would never skip on a production host: runtime security and network egress controls on every runner, governance over which open source packages and actions are allowed to execute, and behavioral monitoring that baselines what each pipeline normally does and flags what it does not. The tools enterprises already own cannot fill this gap. Traditional cloud security watches cloud configuration, endpoint security agents watch employee laptops, and application security tools scan your source code for known vulnerabilities. None of them see what a compromised dependency does at runtime on an ephemeral CI/CD runner.

How StepSecurity Stops Team PCP-Style Supply Chain Attacks

StepSecurity provides runtime security for CI/CD across GitHub Actions, GitLab, and Azure DevOps, and is built on a principle this campaign validates: no single control stops every variant of a supply chain attack, so protection has to come in independent layers spanning prevention, detection, and response. We published a full ten-layer walkthrough against Team PCP's Trivy attack. Here is how the layers map to the attack.

Prevention: the attack fails even when the malicious code runs

Network egress control

Harden-Runner, our runtime security agent, works like an EDR purpose-built for CI/CD runners. In block mode, outbound connections are allowed only to explicitly authorized destinations, so the exfiltration call to a command and control domain is dropped and the secrets never leave the runner. This single control breaks the exfiltration step in every attack in the Team PCP campaign.

Runner lockdown

When malware reads secrets from runner process memory, the way Team PCP's Trivy payload did, Harden-Runner's lockdown mode terminates the job before secrets are collected. This is not theoretical. In almost every major supply chain attack this year, Harden-Runner has caught compromised components after they were already running on runners, at a point when nobody knew the component was compromised yet, across both StepSecurity enterprise and community customers. The evidence for community customers is public: when the ChainDrop worm reached the CI pipelines of Backstage, the CNCF developer portal project, Harden-Runner flagged the C2 traffic as anomalous in real time. You can open that actual workflow run and see the detection yourself.

Workflow Run Policies

Workflow Run Policies act as a pre-execution gate. Every workflow run across your organization is evaluated before any code executes, and any run that references a known compromised component is automatically cancelled. No secrets are exposed and no malicious code runs, covering the gap between the moment a compromise is disclosed and the moment every team has patched its workflow files.

Secure Registry

Secure Registry sits between your CI/CD pipelines and public registries and blocks compromised and freshly published packages at download time, at runtime, before they ever show up on your CI/CD runners.

GitHub Checks

StepSecurity GitHub Checks work in code, before the code is ever executed in CI/CD. Pull requests that introduce compromised or too-fresh package versions fail their checks, so a poisoned dependency bump never merges in the first place.

Dependency governance

Policy-driven pull requests automatically pin actions and images to immutable commit SHAs, so an attacker cannot silently repoint a tag your pipelines trust. StepSecurity Maintained Actions provide hardened drop-in replacements for risky third-party actions.

Detection: behavioral baselines catch what prevention has not reached yet

Harden-Runner

Even in audit mode, Harden-Runner records every outbound network call and every process in every pipeline run and baselines what normal looks like per workflow. First-ever destinations and secret-harvesting process behavior are flagged the moment they appear. When the compromised Trivy action first ran in open source projects monitored by StepSecurity, the connection to the typosquatted exfiltration domain was flagged immediately as an anomaly.

Imposter commit detection

Both the Trivy and KICS attacks used imposter commits: commits reachable by SHA that do not belong to any branch of the source repository. StepSecurity's workflow log analysis automatically flags any action that resolves to an imposter commit, with zero configuration, for every repository that has the StepSecurity app installed.

Response: answer "are we affected?" in real time

Threat Center

Threat Center tells you anytime the platform blocks or detects a malicious component on developer machines, code repositories, or CI/CD, and notifies customers through several notification channels, including SIEM integrations. Behind it sits our AI-powered threat intelligence pipeline: validated indicators from every attack we analyze flow into a Global Block List that is enforced automatically across every customer.

Actions, npm, and PyPI Inventory

When the next compromise is announced, the inventory gives you a complete, queryable map of every GitHub Action, npm package, and PyPI package in use across your organization, including whether each reference is pinned or mutable and which runs executed during the compromise window. Blast radius mapping that normally takes hours of manual grep completes in seconds.

Compromised Package Search

One search pinpoints every place a compromised package landed across developer machines, code repositories, and CI/CD pipelines, not just one stage. This is how you prove you are not impacted, in minutes, while the rest of the industry is still grepping.

This research-to-protection loop is the core of the platform. In H1 2026 alone, StepSecurity discovered or was among the first to report many of the year's most consequential supply chain attacks, and each discovery became automated protection for every customer within hours. That is what it takes to defend against an actor who compounds every win into the next attack.

Check Your Exposure

The 2,186 organizations in this dataset did not know their secrets were leaving until someone published the list. You do not have to wait for that.

For the past: search CloudSEK's exposure lookup for your domain. If you appear, rotate every credential class in the table above and audit for downstream access.

For the future: get started with StepSecurity and leverage Harden-Runner, Secure Registry, GitHub Checks, and Workflow Run Policies to defend against supply chain attacks at every layer of your pipeline. You can add Harden-Runner to a single workflow in minutes and see the complete outbound network map of your next build. Most teams find destinations they never approved on the first run. That visibility is where every real remediation starts.

What Should We Do First If We Are on the List?

If your organization appears in the dataset, work through these four steps in order. Speed matters most on the first one: Team PCP's entire playbook runs on reinvesting stolen credentials before they are rotated.

Rotation without the audit is not enough. The dataset shows what left the runners, not what the attacker has already done with it. And pinning without runtime controls only closes one door: Team PCP's campaign has repeatedly reached runners through dependencies nobody knew were compromised, which is exactly the case runtime and egress controls exist for.

Acknowledgment

Credit to the research team at CloudSEK for cataloging this exposure and publishing its scale. Their work made the pattern visible to the organizations that need to act on it.