TeamPCP shows how cloud identity abuse scales into supply chain compromise

At a glance

What this is: This Gurucul threat profile tracks TeamPCP’s shift from cloud exploitation and credential theft into software supply chain compromise through GitHub, CI/CD, and package channels.

Why it matters: It matters because developer, cloud, and pipeline identities now drive downstream blast radius, so IAM, PAM, and NHI controls have to cover build systems as well as production access.

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.

Context

TeamPCP is a financially motivated threat group that moved from cloud exploitation into software supply chain compromise by abusing trusted developer identities, repositories, and CI/CD workflows. In identity terms, the problem is not just initial access but the ability to turn one trusted foothold into many downstream trust relationships.

For IAM and NHI programmes, this matters because cloud credentials, developer tokens, service accounts, and pipeline permissions all sit on the same attack path once an adversary can reach build systems or source control. The article shows how quickly a compromise can shift from local environment exposure to wider distribution through legitimate software channels.

The author’s progression is typical of modern supply chain crime, not an isolated outlier. Once attackers learn that developer trust can be monetised more effectively than endpoint encryption, they will keep targeting identity at the point where code is built, signed, and distributed.

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. Once API keys, SSH keys, or environment files are stolen, the attacker can reuse those identities across repositories, cloud control planes, and CI/CD systems. The practical consequence is that a single leak can become a multi-system trust failure, not just a one-host incident.

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. Attackers use that access to collect tokens, API keys, and workflow credentials that let them modify code, publish packages, or alter deployment pipelines. The breach path becomes supply-chain-wide once those identities are trusted by automation.

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. Another signal is when the same credentials support both development convenience and release authority. If a compromised job can change code and distribute it, the control boundary is already too loose.

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.

Technical breakdown

How exposed cloud services become credential collection points

TeamPCP’s early workflow used internet-wide scanning to find exposed Docker APIs, Kubernetes clusters, Redis instances, Ray dashboards, and vulnerable Next.js applications. The point was not only code execution. It was to reach configuration files, environment variables, cloud API keys, SSH keys, and other secrets that convert a single server compromise into broader identity access. This is a classic NHI pattern: the application is only the entry surface, while the real asset is the credential set that follows. Practical implication: cloud services exposed to the internet need stronger credential isolation than ordinary server hardening can provide.

Practical implication: reduce credential concentration on exposed cloud hosts and separate runtime secrets from developer and administrative access paths.

Why CI/CD pipelines magnify developer identity risk

Once TeamPCP moved into CI/CD and GitHub workflows, the attack surface changed from isolated hosts to trusted automation. Pipelines routinely hold tokens for source control, package publishing, artifact signing, and cloud deployment, so a single compromised workflow can alter code, steal secrets, or distribute malicious output under legitimate trust. This is where NHI governance becomes supply chain governance: the workflow identity becomes the distribution identity. Practical implication: treat CI/CD permissions as production-grade access, not build-time convenience.

Practical implication: scope pipeline identities to the smallest release function possible and review every secret that can publish or sign artifacts.

Supply chain compromise through trusted software distribution

TeamPCP’s later campaigns show the value of compromising software distribution rather than only individual targets. By reaching repositories, package registries, and developer environments, the actor can inject malicious code into trusted components and let downstream users execute it for them. That changes the economics of breach: one access path can create many victims. For identity teams, the key lesson is that repository and package trust are identity decisions, because they determine who can publish, approve, and propagate code. Practical implication: source control and package publishing authorities must be governed as privileged identities with full lifecycle oversight.

Practical implication: govern repository maintainers, package publishers, and signing credentials as high-value identities with strict offboarding and review.

Threat narrative

Attacker objective: TeamPCP aimed to convert a small number of cloud and developer footholds into repeatable access to software distribution channels, multiplying theft and monetisation opportunities.

1. Entry began with scanning and exploitation of exposed cloud services and vulnerable developer environments, including Docker, Kubernetes, Redis, Ray, and Next.js systems.
2. Credential access followed as the group harvested environment files, cloud credentials, API tokens, SSH keys, and other secrets from compromised hosts.
3. Escalation came through reuse of those credentials to reach repositories, CI/CD workflows, and software distribution channels that already carried trust.
4. Impact emerged when the actor used those trusted channels to distribute malicious code, steal more secrets, and broaden compromise across downstream systems.

Breaches seen in the wild

• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
• GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Developer tokens are the new propagation layer: The article’s central pattern is not malware novelty but identity portability. A stolen token that can reach source control, a package registry, or a CI/CD workflow turns access into distribution. That makes identity lifecycle, offboarding, and privilege scoping the controls that decide whether a compromise stays local or becomes ecosystem-wide.

Trusted software channels collapse conventional perimeter assumptions: When an attacker can publish through legitimate repositories or pipelines, downstream consumers execute the compromise by design. This is why software supply chain risk cannot be handled as a purely application-security problem. The control question is who is allowed to publish, sign, approve, and rotate the identities that make distribution trusted.

Identity blast radius is the right concept for this campaign: TeamPCP demonstrates that the real unit of analysis is not the compromised host but the identity set reachable from that host. Credentials, tokens, and repository permissions form a connected attack graph that can be monetised repeatedly. Security teams should model that blast radius explicitly across cloud, source control, and build systems.

Supply chain compromise now depends on NHI governance discipline: The campaign is a reminder that service accounts, CI/CD tokens, package publishers, and cloud credentials all behave like privileged non-human identities once they can alter code or release artifacts. Governance gaps in ownership, rotation, and revocation give attackers a durable way to scale from one compromised environment into many downstream targets.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Identity blast radius is the core planning metric here: once a cloud credential can reach GitHub, a pipeline, or a package registry, the question is no longer whether a server is compromised but how far that identity can propagate. Security teams should map those reuse paths before they become attacker-owned distribution routes.

TeamPCP also reinforces that cloud and supply chain governance are now linked through the same control surface: tokens, service accounts, and workflow permissions. The practical response is to move review and revocation closer to issuance, because post-compromise review often arrives after the code has already spread.

According to the Ultimate Guide to NHIs 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. That figure matters here because third-party access and downstream distribution risks are the same governance problem seen from different angles.

For practitioners

• 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.
• Separate developer credentials from host credentials Avoid storing cloud admin keys, SSH keys, or package tokens on the same endpoint that developers use for daily work, especially in build-adjacent systems.

Key takeaways

• TeamPCP’s campaigns show how cloud compromise becomes supply chain compromise when developers, pipelines, and repositories share trust boundaries.
• The article links the group to exposed cloud services, credential theft, CI/CD compromise, and GitHub repository access, showing a repeatable progression in attack maturity.
• The control gap is not just detection after compromise. It is lifecycle governance for the identities that can publish, sign, deploy, and propagate code.

Key terms

• Cloud identity abuse: The misuse of a valid cloud account, access key, token, or role to perform actions that appear legitimate to the provider. In practice, the attacker does not need to break authentication again once the credential is stolen, so the environment’s own trust model becomes the attack surface.
• CI/CD Identity: CI/CD identity is the set of credentials and permissions used by build, test, and deployment systems to act in software delivery pipelines. It includes service accounts, tokens, keys, and certificates that let automation access code, artifacts, cloud resources, and deployment targets. Strong governance limits exposure, scope, and lifetime.
• Supply Chain Blast Radius: Supply chain blast radius is the amount of downstream infrastructure an attacker can affect after compromising one dependency or build step. In dependency-rich systems, a flaw in a common library can reach repositories, signing systems, cloud resources, and customer-facing services if permissions are not tightly separated.
• Developer Credential Sprawl: Developer credential sprawl is the uncontrolled spread of keys, tokens, SSH material, and secrets across endpoints, applications, and build pipelines. The risk is not just exposure but reuse, because one stolen credential can unlock multiple trusted workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.