TeamPCP supply chain attacks expose CI/CD credential risk

At a glance

What this is: This is SafeBreach’s coverage of FBI FLASH-20260702-01 on TeamPCP, a supply chain campaign that used trojanized packages and developer tools to steal credentials and create persistence in CI/CD environments.

Why it matters: It matters because CI/CD pipelines, package registries, and build tooling now sit inside the identity perimeter, so IAM and NHI teams have to govern tokens, secrets, and publishing rights as active attack paths.

Context

TeamPCP is a supply chain attack pattern, not just a malware family. The issue is that trusted build and publishing paths can be turned into identity attack surfaces when attackers compromise package updates, CI/CD runners, and the credentials those systems can reach.

SafeBreach’s coverage of FBI FLASH-20260702-01 frames the problem as credential theft through software distribution channels, with cloud tokens, SSH keys, Kubernetes secrets, and publishing access all at risk. For identity teams, the lesson is that build trust and access trust are now the same control plane.

The campaign is typical of modern supply chain abuse: compromise a trusted component, inherit the trust of downstream automation, and use that trust to expand access silently across environments.

Key questions

Q: What breaks when a software supply chain attack reaches CI/CD credentials?

A: The trust model breaks when build and publishing systems can read secrets that were never meant to leave the pipeline. At that point, a package compromise becomes an identity compromise, because the attacker can reuse cloud tokens, SSH keys, and registry access to move beyond the initial infected component.

Q: Why do CI/CD runners create a higher compromise risk than many teams expect?

A: CI/CD runners often have privileged access to source code, secrets, build tools, and release systems, which makes them attractive to attackers. If a runner is compromised, an attacker can steal credentials, alter artifacts, or inject malicious steps during trusted automation. This is why pipeline security needs runtime visibility and enforcement, not just pre-build scanning.

Q: What are the signs that supply chain malware is abusing trusted automation?

A: Look for unexpected repository creation, unusual outbound connections from runners, secret access outside normal job steps, and package updates that introduce new persistence or credential theft behaviour. Those signals often show that trusted automation has become a collection and propagation channel.

Q: Should teams prioritise package verification or runtime monitoring first?

A: They need both, but runtime monitoring should close the gap that package verification cannot see. Verification helps with source integrity, while runtime controls show whether trusted code is reading secrets, creating repositories, or exfiltrating data after execution begins.

Technical breakdown

How supply chain compromise becomes credential exposure

TeamPCP’s entry path was software supply chain compromise, where malicious code was injected into legitimate packages and trojanized updates were delivered through trusted developer tooling. Once that code ran inside build or security workflows, it inherited the environment’s local trust relationships, including access to cloud tokens, registry credentials, and service account material. This is the core supply chain problem: signed or familiar software can still behave as an identity collection point after execution. The FBI’s framing shows why package integrity alone does not protect runtime credentials.

Practical implication: verify package provenance, but also monitor what trusted software can read, mint, or exfiltrate after it starts running.

Why CI/CD runners are high-value identity targets

CI/CD runners are transient compute, but their privilege is often durable. They hold secrets for deployment, testing, package publishing, and infrastructure access, which makes them attractive for credential harvesters and supply chain worms. In this campaign, stolen GitHub Personal Access Tokens were used to create attacker-controlled repositories, showing how one compromised automation account can expand into organisation-wide abuse. The architectural failure is not just exposure of one secret. It is the concentration of multiple downstream privileges inside a system assumed to be ephemeral and trusted.

Practical implication: treat CI/CD runners as privileged identity endpoints and restrict what tokens and secrets they can reach.

How worm-like propagation weaponises publishing trust

Mini Shai-Hulud and Miasma show how supply chain attacks escalate once publication credentials are compromised. Instead of stopping at a single host, the malware replicated across npm and PyPI, poisoned configuration files, and moved through publishing trust to reach more packages and more organisations. That turns a single credential theft event into a multi-tenant propagation problem. For practitioners, the mechanism matters because the attacker does not need to break each environment separately once registry trust and maintainer access are already in hand.

Practical implication: segment publishing rights, validate maintainer access continuously, and assume one stolen publishing token can affect many downstream consumers.

Threat narrative

Attacker objective: The objective was to turn trusted software channels into credential collection and propagation infrastructure for persistent access and extortion.

1. Entry occurred through software supply chain compromise, where malicious updates were injected into legitimate packages and developer tools.
2. Credential access followed when the malicious code harvested cloud access tokens, SSH keys, Kubernetes secrets, and other authentication material from build and developer environments.
3. Escalation and lateral movement occurred when stolen GitHub Personal Access Tokens were used to create attacker-controlled repositories and when the worm propagated across npm and PyPI.
4. Impact came through extortion, public leak-site naming, and the long-tail reuse of stolen credentials across downstream systems.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

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

CI/CD trust has become identity trust: supply chain compromise now lands in the same governance problem space as secrets management and privileged access. When build systems can read deployment tokens, registry credentials, and cloud secrets, the pipeline is no longer just a delivery mechanism. Practitioners should treat software distribution paths as governed identity surfaces, not passive tooling.

Runtime validation is the missing control layer: package verification answers whether code was signed or expected, but not what the code does after execution begins. TeamPCP shows why build-time trust cannot be the only assurance boundary when malware can read secrets at runtime and persist inside automation. The implication is that identity governance has to extend into execution behaviour, not stop at artifact provenance.

Publishers and runners share the same blast radius: stolen publishing tokens, maintainer accounts, and CI/CD service credentials create a single compromise path from one ecosystem to many. That is why least privilege and lifecycle governance must cover both the runner and the registry account, not one or the other. Practitioners should collapse the assumption that publishing access is operational, not strategic.

Short-lived secrets do not help if trust is over-broad: rotating credentials after compromise is necessary, but the deeper issue is that too many systems still expose secrets to tooling that does not need them. The campaign demonstrates credential overexposure through shared automation paths, which is a structural NHI governance failure. The right programme question is which credentials should never be reachable from build and security tooling in the first place.

Supply chain worms are a lifecycle problem, not only a malware problem: once a compromised package or token can be reused, offboarding and revocation become part of the threat model. That means access reviews, token scoping, and maintainer hygiene belong in the same governance conversation as dependency security. Practitioners should align NHI lifecycle controls with software supply chain controls rather than treating them as separate workstreams.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

CI/CD secret exposure is now a governance problem, not a pipeline hygiene issue: build systems frequently hold enough privilege to become identity attack surfaces. The practical shift is to govern runner access, publishing rights, and secret reach as part of the same control set that manages NHI risk.

Supply chain compromise now depends on who can execute, publish, and reuse credentials: the attacker objective is often not code execution alone, but credential inheritance across automation and registries. That changes how teams should evaluate least privilege in build tooling and package maintenance.

Secret sprawl and third-party exposure make this pattern durable: according to the State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. Practitioners should expect attackers to keep targeting the systems that already hold the most trust.

For practitioners

• Pin package and workflow trust Bind CI/CD workflows to verified commit SHAs, fixed dependencies, and reviewed publishing paths so malicious version drift cannot ride on floating references.
• Scope CI/CD credentials aggressively Restrict runner tokens, publishing tokens, and cloud credentials to the minimum repository, registry, and cloud actions required for each pipeline step.
• Rotate secrets after exposure windows Revoke cloud access tokens, SSH keys, Kubernetes secrets, and registry credentials that were reachable during the compromise window, then reissue from governed sources.
• Monitor runners for abnormal behavior Add runtime telemetry for unexpected outbound connections, secret reads, and repository creation activity from CI/CD runners and build containers.
• Audit maintainer and publishing access Review package maintainer accounts, recovery paths, and publishing rights for stale access that could let an attacker inherit trust across ecosystems.

Key takeaways

• TeamPCP shows that software supply chain compromise can become credential theft when trusted build and publishing paths are allowed to reach high-value secrets.
• The campaign used malicious package updates, stolen publishing tokens, and cross-ecosystem propagation to turn one compromise into broader downstream exposure.
• Practitioners need to govern CI/CD runners, package publishers, and cloud secrets as one identity problem, not three separate ones.

Key terms

• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Publishing Credentials: Publishing credentials are the authentication secrets that allow a person or system to release software to a package registry. They are high-value non-human or human-access secrets because compromise can let an attacker distribute malicious updates under a trusted project name.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.