The thing that should worry you about TeamPCP is not the scale, though the scale is real. It is the discipline. Most supply chain compromises read like opportunistic smash-and-grab: one maintainer phished, one package poisoned, a payload that fires once and burns out. TeamPCP reads like an operations team running a pipeline. Reconnaissance feeds initial access. Initial access feeds credential harvesting. Harvested credentials feed the next compromise. The output of one campaign is the raw material for the next, and the cadence does not slow down.
By the security community's accounting, TeamPCP, designated UNC6780 by Google's Threat Intelligence Group, is the single most active actor in the open-source and AI developer supply chain through the first half of 2026. According to a malicious-package intelligence corpus maintained by Phoenix Security, the broader landscape it tracks spans roughly 59 documented campaigns and 657 malicious package indicators across npm, PyPI, VS Code, and AI agent tooling, with the first half of 2026 alone accounting for the bulk of that volume and TeamPCP responsible for a disproportionate share of the high-impact waves. The detail that matters most for defenders: across that corpus, the number of CVEs assigned during active exploitation was reportedly zero.
A Zero-CVE Campaign Breaks Your Mental Model
Sit with that zero for a second. Your vulnerability management program, your patch Tuesday rhythm, your CVE feeds, your "critical and high get patched in 30 days" SLA, all of it assumes the threat arrives with an identifier attached. TeamPCP's activity largely did not.
This is not a CVE problem because nothing was "vulnerable" in the traditional sense. The code was not flawed. The code was malicious, signed and shipped by accounts that legitimately had publish rights, distributed through the exact channels your build system is configured to trust. There is no patch for a package that was working as the attacker intended. A scanner doing database lookups against known CVEs will return a clean bill of health while a credential stealer runs in your CI pipeline.
If your supply chain security strategy is "scan dependencies for known CVEs and patch fast," TeamPCP is the case study for why that is necessary but nowhere near sufficient. The interesting attacks in 2026 do not have CVE IDs. They have provenance problems.
The Operation: Compromise the Compromisers
What separates TeamPCP from the noise is target selection. The group went after security tooling, the software that developers install specifically to be safe.
In mid-to-late March 2026, the group reportedly hit Aqua Security's Trivy. Reporting indicates they exploited an incomplete credential rotation following an earlier minor breach, took over the build service account, and force-pushed malicious code across nearly all of the version tags of the trivy-action GitHub Action. Because GitHub Actions are commonly referenced by mutable tag rather than pinned commit SHA, every pipeline pulling that action by tag pulled the implant on the next run. Reporting put the blast radius in the thousands of workflow files referencing the action.
Days later they reportedly moved on Checkmarx KICS, another infrastructure-as-code scanner, using stolen GitHub Personal Access Tokens harvested from the earlier wave. The pattern holds: the loot from one compromise is the access for the next. Subsequent reporting tied the group to the LiteLLM AI gateway on PyPI, to a wave of @tanstack/* npm packages (reporting describes 84 malicious versions across 42 packages around May 11), and to a poisoned VS Code extension with a very large install base that harvested developer secrets directly from the IDE's local environment.
That extension is the part that should keep platform teams up at night. The stolen credentials reportedly proved sufficient to exfiltrate a large set of internal source repositories from a major developer platform, with figures cited in the thousands. Estimates vary by source, and you will see different counts depending on who is reporting, so treat any single precise number with caution. The direction is what matters: the developer's own machine, and the trust surface of the IDE, became the exfiltration path.
OAuth Token Theft and CI/CD Are the Real Targets
Strip away the package names and a consistent payload objective emerges. TeamPCP's implants were built to harvest secrets: GitHub PATs and OAuth tokens, npm publish tokens, cloud credentials for AWS, GCP, and Azure, SSH keys, Kubernetes secrets, database credentials, and the contents of CI/CD environment variables.
This is OAuth token theft and CI/CD compromise dressed up as a package problem. The package is the delivery mechanism. The token is the prize, because a token is portable, often long-lived, and frequently over-scoped. Once the implant has a publish token, it can push the next malicious version. Once it has a cloud credential, it can move laterally into infrastructure that no dependency scanner is even looking at. The self-propagating waves attributed to this lineage, echoing the earlier Shai-Hulud worm, work precisely because a stolen npm token lets the malware publish itself into the next set of packages without a human in the loop.
The lesson is uncomfortable: your CI/CD system is one of the most privileged, least monitored execution environments you own. It runs arbitrary third-party code on every build, holds the credentials to ship to production, and most teams audit it less than they audit a laptop. TeamPCP understood this better than most defenders do.
What Actually Stops This
There is no single control that beats an actor like this, but there are a few that change the economics meaningfully, and none of them are exotic.
Pin everything by digest. Reference GitHub Actions by full commit SHA, not by tag. Pin container images by digest, not by latest. The Trivy tag rewrite worked because mutable references silently absorb whatever the attacker pushes. Immutable references break that.
Treat provenance as a gate, not a report. You want to know, before a build runs, whether a package version's signature, build attestation, and publishing identity match what you expect. A version that suddenly appears outside the maintainer's normal release pattern, from a new identity, in a 35-minute burst, should fail closed.
Scope and shorten credentials ruthlessly. Long-lived PATs and broad cloud keys in CI are the fuel for the whole pipeline. Short-lived, narrowly scoped, workload-identity-based credentials make a stolen token far less useful and far more detectable.
Watch behavior, not just bills of materials. A scanner telling you a package has no known CVE says nothing about whether its install script just phoned home. Postinstall hooks reaching the network, builds reading unexpected secrets, packages published off-cadence, these are the signals that catch a zero-CVE compromise.
How Safeguard Helps
This is the class of threat Safeguard is built for, because it lives in the gap between "no known CVE" and "obviously fine." Our AIBOM and ML-BOM give you a real inventory of what is actually executing in your pipelines, including AI tooling like gateways and extensions, and our provenance and attestation checks flag packages whose publishing identity, signature, or release cadence does not match the expected baseline, the exact anomaly pattern behind the Trivy, durabletask, and TanStack waves. Policy gates let you fail a build closed on unpinned actions, off-cadence versions, or missing attestation rather than discovering the problem after deployment, while the vendor scorecard and TPRM workflows keep the third-party security tools you depend on under the same scrutiny as everything else. The platform is model-agnostic, with reliability living in the verification and orchestration layer above any single model, so multi-agent verification cuts the false positives that make behavioral signals unusable at scale. If you want to pressure-test your CI/CD and dependency trust surface against TeamPCP-style tradecraft, reach out.