Topic starter
09/07/2026 1:41 pm
TL;DR: TeamPCP moved from exploiting exposed cloud services and stealing credentials to compromising GitHub repositories, CI/CD pipelines, and package ecosystems, with public reporting linking the group to more than 59,000 compromised systems in one campaign and 3,800 internal repositories in another, according to Gurucul. The pattern shows that developer identity and pipeline trust now define downstream blast radius more than perimeter controls do.
Editorial analysis by NHI Mgmt Group, based on content published by Gurucul: “Threat Actor Profile – TeamPCP”.
By the numbers:
- The group’s operations demonstrated a progression from late 2025 cloud exploitation to mid-2026 software supply chain attacks.
- Gurucul says GitHub confirmed unauthorized access to approximately 3,800 internal repositories.
Key questions
Q: What breaks when cloud credentials are exposed in developer environments?
A: Exposed cloud credentials break the assumption that development systems are low-risk staging areas.
Q: Why do exposed cloud services so often lead to supply chain compromise?
A: Because the services frequently hold secrets that are more valuable than the server itself.
Q: What are the signs that CI/CD identity controls are too broad?
A: Warning signs include workflow tokens that can publish artifacts, access multiple repositories, or reach cloud environments beyond one build job.
Practitioner guidance
- Harden exposed cloud entry points Inventory internet-facing Docker, Kubernetes, Redis, Ray, and developer application surfaces, then separate them from any credential stores or deployment secrets they can reach.
- Reduce pipeline trust in build automation Limit CI/CD jobs to the narrowest publish, sign, or deploy functions they actually need, and remove long-lived tokens from workflow contexts.
- Govern repository and package publish rights as privileged access Treat maintainer, publisher, and signer permissions as high-value identities with named owners, periodic review, and immediate revocation paths.
Bottom line: TeamPCP’s campaigns show how cloud compromise becomes supply chain compromise when developers, pipelines, and repositories share trust boundaries.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 1:45 pm
Cloud identity is now a supply chain control, not just an infrastructure control: TeamPCP shows that exposed cloud services are valuable primarily because they lead to developer credentials, tokens, and automation rights. Once those identities are reused across repositories and pipelines, the blast radius extends well beyond the original host. Practitioners should treat cloud identity governance as part of software distribution security, not a separate programme.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams decide who can publish or sign software artifacts?
A: Use the same discipline you would apply to privileged access. Limit publish and signing rights to named roles, require ownership, and make offboarding immediate when a maintainer, service account, or automation path is no longer needed. The goal is to stop trusted channels from becoming unaudited propagation paths.
👉 Read our full editorial: TeamPCP shows how cloud identity abuse scales into supply chain compromise