You've probably seen the headlines. Bitwarden compromised. Trivy compromised. Checkmarx tools compromised. A handful of other developer tools before that. Each one got its own news cycle, its own advisory, its own "here's what to do if you're affected" post. Each one felt like a separate story.

They're not separate stories.

Every one of those incidents traces back to a single threat actor group called TeamPCP, and more importantly, to a single initial compromise that happened in December 2024. What we've been watching play out over the past several months isn't a wave of new attacks.

It's one attack, still expanding, with victims still being discovered and credentials still being used that were stolen over a year ago.

That framing matters, because if you're evaluating your organization's exposure one headline at a time, you're already behind.

How Build Pipelines Became the Target

Here's the short version of how this works. Modern software doesn't get built in isolation. The tools developers use to build, test, and deploy software are themselves software and they run in automated pipelines that have access to a remarkable number of sensitive credentials. Cloud provider keys. Database passwords. API tokens. Deployment certificates. All of it sits in the build environment, because the build process needs it to do its job.

TeamPCP figured out that if you can get into one of those pipelines, you don't just get into one organization. You get into every organization running that tool. And if the tool you've compromised is something like Bitwarden's CLI — a password manager used by security-conscious IT teams specifically because they trust it — the irony is almost too on the nose.

How the Campaign Unfolded

The initial foothold was a small open-source Java tool most people have never heard of. From there, TeamPCP moved laterally through trust relationships between open-source maintainers until they were inside the build pipeline of tj-actions/changed-files, a workflow utility used by over 23,000 software projects. When that compromised tool ran, it quietly collected credentials from every pipeline it touched. That was March 2025. CISA issued an advisory. People patched. The news moved on.

But TeamPCP did not move on. They sat on the credentials they'd collected, mapped out where they could go next, and started spending that access methodically. Trivy, the most widely-deployed open-source security scanner in cloud environments, got hit in March 2026… just a year later. Then Checkmarx tools. Then LiteLLM. Then Bitwarden's CLI delivery pipeline last month. Each compromise either used credentials from a previous one, or exploited the same class of misconfiguration that worked before. The campaign didn't restart between incidents. It just continued.

The part that should concern any IT or security team isn't the list of tools that got hit. It's the timeline. There's roughly a year between when credentials were first collected at scale and when some of the downstream impact is showing up now. That gap is not an accident. TeamPCP is patient. They're not burning access the moment they get it. They're holding it, using it selectively, and in some cases the organizations that were exposed in 2025 are still finding out about it in 2026.

The Ransomware Dimension

There's also a ransomware dimension developing here. A Ransomware-as-a-Service (RaaS) group called Vect publicly announced a partnership with TeamPCP specifically to monetize the credential haul from these campaigns. Their first confirmed ransomware victim appeared in April 2026.

Attribution is still evolving and the picture is messy, but the operational implication is clear enough: credentials stolen from CI/CD pipelines are being converted into ransomware deployments. That process is active and ongoing. 2026 is shaping up to be the worst year for supply chain attacks on record, and we're not even halfway through the second quarter.

TeamPCP publicly stated on their Telegram channel that they intend to keep operating: “These companies were built to protect your supply chains yet they can't even protect their own... we're gonna be around for a long time stealing terrabytes [sic] of trade secrets with our new partners.” They've claimed to have accumulated 300 GB of compressed credentials. The attack model they've built — get inside a trusted tool, collect credentials at scale, spend them slowly — doesn't require them to find new vulnerabilities. It just requires organizations to keep trusting tools without asking hard questions about how those tools are built and distributed.

Most of them will.

What This Means for Your Organization

Understanding the shape of this campaign is step one. The headlines made it easy to treat each incident as its own contained problem with its own contained fix. That framing let a lot of organizations close the tab and move on. But the exposure from a supply chain compromise at this scale doesn't resolve when the vendor patches the vulnerability. It resolves when every credential that passed through the affected environment has been identified, assessed, and rotated. That work is harder, slower, and less satisfying than applying a patch.

Next week, we’ll get into what your organization should be doing right now: the questions to ask your vendors, how to think about credential rotation after a supply chain event, and what separates the organizations that will handle this well from the ones that will find out about their exposure in the next round of headlines.

See you for Part 2.