Static credentials turned one stolen token into a five-ecosystem breach

At a glance

What this is: This is an analysis of the TeamPCP supply chain campaign and the key finding is that static credentials in runtime environments enabled one token theft to cascade across five ecosystems.

Why it matters: It matters because IAM, NHI, and PAM teams cannot treat secret rotation or dependency pinning as complete defences when durable credentials remain reachable during execution.

👉 Read Defakto Security’s analysis of the TeamPCP static credential chain reaction

Context

Static credentials are secrets that remain usable during runtime, which makes them attractive to attackers once a single environment is compromised. In the TeamPCP chain, that persistence turned one personal access token into repeated access across CI, package registries, container infrastructure, and developer environments. This is a supply chain and NHI governance problem, not just a workflow misconfiguration problem.

The core issue is trust inheritance. If one runtime environment can read a durable credential, every downstream system that accepts that credential becomes part of the blast radius. For identity programmes, that means secret discovery, lifecycle control, and short-lived workload identity must be treated as one operating model rather than separate projects.

Key questions

Q: What fails when static credentials are used in CI/CD pipelines?

A: Static credentials fail because they remain reusable during execution, so any compromise of a runner, workflow, or dependency can expose secrets that unlock other systems. In practice, one leaked token can cascade into package registries, container repos, and production environments. The control failure is not only exposure, but the lack of a narrow runtime boundary for reuse.

Q: Why do static service credentials increase supply chain blast radius?

A: Static service credentials increase blast radius because they create trust that survives beyond the specific action that needed it. If the same token is valid in CI, build tooling, and publishing systems, an attacker can move laterally without new exploitation. That makes inventory, least privilege, and short-lived identity more important than pinning alone.

Q: How can teams tell whether secret rotation is actually reducing risk?

A: Teams should look at whether a rotated secret was ever exposed at runtime, whether it still works in downstream systems, and how quickly it can be revoked everywhere it matters. Rotation only reduces risk if the old credential cannot be reused and the replacement is not injected as another durable secret. Otherwise, the attack window remains open.

Q: What should security teams do when a build token is stolen?

A: Security teams should first identify every system that accepted the token, then revoke trust at each downstream integration before the attacker can reuse it. The immediate goal is to stop replay across registries, workflows, and developer environments, not just to rotate one secret. That requires dependency mapping and ownership clarity.

Technical breakdown

How pull_request_target became an entry path for credential theft

The pull_request_target event in GitHub Actions runs with the target repository’s privileges, which is why it is dangerous when untrusted code can influence the workflow. In this case, a misconfiguration let an attacker trigger privileged execution from a pull request that was opened and closed immediately. That provided access to a personal access token with write privileges to repository secrets. The technical lesson is not just about one workflow trigger. It is about how privileged automation can become an exfiltration surface when the job context includes durable secrets.

Practical implication: restrict privileged workflow triggers and remove static secrets from jobs that process untrusted input.

Why static secrets cascade across CI, registries, and developer machines

A static credential is reusable by design, so once it is exposed, it can be replayed anywhere the trust boundary accepts it. The article shows a chain from GitHub Actions to npm, Docker Hub, PyPI, and local developer environments. That is credential cascades in practice: one token exposes another environment, which exposes the next secret, until the attacker can move laterally without new exploits. Scanners can detect some leaks, but they do not break the chain while the secret remains valid and reachable during execution.

Practical implication: inventory where static secrets live, then replace the most reusable ones first because each exposed token can unlock the next system.

Why short-lived workload identity changes the control model

Short-lived workload identity changes access from possession-based trust to runtime-issued trust. Instead of injecting a long-lived token into an environment variable, the workload proves identity at execution time and receives scoped credentials for a narrow action window. That is why standards such as SPIFFE, OIDC, and OAuth matter here. They let teams bind identity to the workload and limit reuse if a build runner, package publisher, or developer workstation is compromised. The architecture does not eliminate compromise, but it sharply reduces credential durability and replay value.

Practical implication: move CI/CD and workload access to runtime-issued identity so a stolen secret cannot survive long enough to spread.

Threat narrative

Attacker objective: The objective was to convert one stolen runtime token into multi-ecosystem supply chain access, package poisoning, and broad credential theft.

1. Entry occurred when the attacker exploited the pull_request_target misconfiguration in Trivy’s GitHub Actions workflow and obtained a personal access token with write access to repository secrets.
2. Credential abuse followed as the attacker reused the stolen token to force-push malicious tags, publish compromised releases, and pivot into npm, Docker Hub, and PyPI environments.
3. Impact expanded as the campaign spread across five ecosystems, compromised 66 packages, and exfiltrated 54GB of data from CI, developer, and production environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static credentials are the failure condition, not just the attack surface. TeamPCP worked because every environment touched by the chain had a durable secret waiting to be read at runtime. That is a governance failure, not a tooling failure, because scanners and vaults still leave possession-based trust intact. The implication is that identity teams must stop treating secret storage as the control objective and start treating secret survivability as the risk.

Credential cascades create an identity blast radius that most supply chain programmes do not measure. One stolen token moved from GitHub Actions to package registries, container distribution, and developer machines because each environment trusted the same class of reusable secret. OWASP NHI and NIST CSF both point toward better inventory and access governance, but this article shows why blast radius must become a first-class metric. Practitioners should think in terms of how far a single credential can travel before it is blocked.

Just pin it is an incomplete control because pinning does not change runtime possession. Commit SHAs, image digests, and signed releases reduce ambiguity about what code is running, but they do not stop that code from reading static credentials once execution starts. The governance gap is the assumption that supply chain integrity alone constrains post-execution abuse. Teams should treat code provenance and runtime identity as separate control planes.

Short-lived identity should replace durable secrets wherever automation can authenticate cryptographically. The article’s proposed direction is consistent with modern workload identity design, where access is issued just in time and scoped to a single run or action. That shifts teams away from broad, reusable tokens and toward verifiable runtime identity for pipelines, build runners, and developer tooling. The practitioner conclusion is that static secret removal is an identity redesign exercise, not a secret hygiene project.

Discovery is the prerequisite to any credible NHI governance programme. The article is right to start with mapping because organisations cannot revoke, rotate, or replace what they cannot see. That is especially true when static credentials are spread across CI, staging, developer laptops, and third-party systems. The practical conclusion is that visibility into non-human identity inventory determines how quickly an organisation can contain a real incident.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader governance lens, review the Secret Sprawl Challenge for how teams can map exposed credentials before they become reusable attack paths.

What this signals

Credential survivability will become a board-level metric. Teams that still measure only detection coverage are missing the operational question that matters most: how long a secret remains usable after exposure. With 64% of valid secrets leaked in 2022 still exploitable today, the governance problem is persistence, not discovery.

The next phase of NHI governance will converge discovery, ownership, and revocation into one control loop. That is where static secrets, workload identity, and access lifecycle management meet. Programmes that cannot tell where a token lives, who owns it, and how quickly it can be killed will keep inheriting the same blast radius.

Identity blast radius: the measurable extent to which one credential can propagate access across CI, registries, developer machines, and production systems. Teams should use that concept to prioritise remediation, because the highest-risk secrets are the ones that can travel furthest before they are blocked.

For practitioners

• Map every static credential path Build a complete inventory of personal access tokens, publish tokens, API keys, and cloud keys across CI/CD, developer machines, staging, and third-party integrations. Prioritise secrets that can be reused outside the system that issued them, because those create the widest blast radius.
• Remove static secrets from privileged build paths Replace environment-variable injection in workflows with runtime-issued identity where the job proves itself at execution time. Use short-lived credentials for CI runs, package publishing, and container operations so a stolen token cannot be replayed across ecosystems.
• Harden workflow triggers and trust boundaries Review any GitHub Actions or similar automation that runs with elevated privileges on untrusted input. Separate secret-bearing jobs from pull request contexts, and deny write access to repository secrets unless the workflow can be cryptographically trusted.
• Measure credential survivability, not just rotation Track how long a secret remains valid after discovery, where it is reachable at runtime, and how many downstream systems accept it. A token that can still be used hours or days later is still an active attack path even if the secret has been rotated elsewhere.

Key takeaways

• The breach worked because durable credentials were still available at runtime, turning one stolen token into a multi-ecosystem chain reaction.
• The scale mattered because the campaign crossed five ecosystems and exposed 54GB of data, showing that one secret can become a systemic supply chain event.
• The control that would have changed the outcome is short-lived workload identity, supported by discovery of every static secret path and aggressive downstream revocation.

Key terms

• Static Credential: A static credential is a long-lived secret such as a token, key, or certificate that can be reused until it is rotated or revoked. In identity governance, its main risk is durability: once exposed at runtime, it can be replayed across environments and often survives long enough to fuel lateral movement.
• Credential Cascade: Credential cascade is the pattern where one exposed secret reveals access to another system, which then exposes the next secret in sequence. It is a common supply chain failure mode because reusable credentials let attackers move from one trusted environment to the next without needing a new exploit.
• Workload Identity: Workload identity is a runtime-issued identity assigned to software, pipelines, or services so they can authenticate without embedding durable secrets. It replaces possession-based trust with cryptographic proof at execution time, which limits replay and reduces the blast radius of compromise.

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.

This post draws on content published by Defakto Security: Real-World Lessons Chain Reaction, how one stolen token tore through five ecosystems. Read the original.