GitHub Actions supply chain attack exposes identity security gaps

At a glance

What this is: This is an analysis of a GitHub Actions supply chain attack that weaponised a compromised workflow dependency to expose CI/CD secrets across thousands of repositories.

Why it matters: It matters because CI/CD runners, workflow tags, and build logs are part of the identity plane, so IAM and NHI teams have to govern them like privileged access paths, not just developer tooling.

👉 Read Unosecur's analysis of the GitHub Actions supply chain attack and identity exposure

Context

GitHub Actions supply chain attacks show how pipeline identity can become a privileged access path when mutable workflow dependencies are trusted by default. In this case, a compromised action used version tags to deliver malicious code into CI/CD runs, which is an identity security problem as much as a software supply chain problem.

The governance gap is not limited to code integrity. CI/CD runners often hold secrets, environment variables, and tokens that were never meant to be broadly observable, yet workflow logs can turn those credentials into a reusable attack asset when masking or logging controls fail.

For IAM and NHI programmes, the key issue is that machine identities in build systems often operate with standing permissions and weak lifecycle governance. That makes GitHub Actions a useful case study in how identity controls break when automation is treated as low-risk infrastructure.

Key questions

Q: What breaks when mutable GitHub Actions or package tags are allowed in CI pipelines?

A: Mutable tags let the attacker choose the code that runs first, before the intended build or scan logic. In practice, that means a trusted workflow can become an execution path for credential theft, registry token capture, or dead-drop creation. The control failure is not just dependency risk, but lack of immutable references and provenance enforcement.

Q: Why do compromised developer and CI hosts create such a large identity risk?

A: They often hold non-human credentials with broad privileges, including repository write access, pipeline secrets, and cloud authentication material. That makes them attractive pivot points because one malicious dependency can expose multiple identity domains at once. The risk is highest when those credentials are reusable, long-lived, or mounted into jobs by default.

Q: What are the signs that a GitHub Action compromise may have exposed secrets in CI logs?

A: Look for unexpected workflow behaviour, suspicious outbound network requests, and runner logs that include dumped environment data or encoded blobs. In this incident pattern, public CI logs are especially risky because secrets can be printed directly to stdout. Any repository that used the affected action should be assumed exposed until reviewed and rotated.

Q: How should teams reduce the blast radius of a compromised third-party action?

A: Constrain the action to the minimum required permissions, remove static secrets from the runner, and require immutable references for external dependencies. If the action is compromised, the damage stays inside the task scope instead of spreading across cloud and source control systems.

Technical breakdown

Mutable workflow tags as an identity control failure

GitHub Actions commonly reference reusable actions through version tags such as v1. That convenience creates a trust boundary: if the referenced repository is compromised, the same tag can be repointed to malicious code without changing downstream workflow definitions. In identity terms, the build pipeline is delegating execution authority to a third party with mutable identity. The attack succeeded because the runner trusted the tag, not an immutable commit reference. This is why pinned versions matter: they narrow the window in which a trusted action can be silently replaced.

Practical implication: Pin workflow dependencies to immutable commit SHAs and review any action that can change behaviour without a configuration diff.

CI/CD runners as privileged non-human identities

CI/CD runners execute with permissions that frequently exceed those of ordinary application code. They can read environment variables, access cloud tokens, and interact with repositories, package registries, or deployment targets. That makes the runner a non-human identity with delegated privilege, not just an execution host. When the malicious script ran inside the runner, it inherited the workflow’s access scope and could inspect memory for credentials. The core failure is excessive trust in the runtime context rather than a classic user-account compromise.

Practical implication: Treat runner permissions as a governed NHI credential surface and scope them to the minimum task needed for each workflow.

Workflow logs turned secret exposure into an access path

The attackers bypassed secret masking by double Base64-encoding the stolen values before printing them to logs. GitHub’s redaction logic did not recognise the transformed strings, so credentials became visible in plaintext after decoding. This is a classic secret-handling failure: once a secret is written to a broadly accessible log, it stops being a control and becomes an attack artifact. The exposure risk extends beyond GitHub itself because the leaked credentials included access to cloud platforms and package systems.

Practical implication: Assume workflow logs are sensitive data stores and prevent any secret-bearing output from being written there in the first place.

Threat narrative

Attacker objective: The objective was to harvest reusable CI/CD credentials and use them to broaden access across cloud, code, and package environments.

1. Initial access occurred when attackers gained control of the tj-actions/changed-files repository and repointed existing version tags to malicious code.
2. Credential access followed when the compromised action executed inside CI/CD runners and scanned memory for authentication tokens, cloud keys, and GitHub secrets.
3. Exfiltration happened when the stolen secrets were printed into workflow logs in a masked-by-obfuscation format that users could decode.
4. Impact was the potential reuse of leaked credentials to access cloud accounts, modify repositories, and compromise package integrity.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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

NHI Mgmt Group analysis

Mutable workflow identity is now a supply chain control, not a convenience feature: Version tags in CI/CD behave like delegated identities, which means they need the same change control and verification discipline as any other privileged access path. When a tag can be repointed, trust attaches to a label instead of a known code state. Practitioners should treat mutable references as a governance defect, not a developer preference.

Pipeline runners are non-human identities with hidden blast radius: The attack worked because the runner held secrets that were useful far outside the build step itself. That makes the build environment part of the identity perimeter, especially when cloud tokens, PATs, and package credentials coexist in the same execution context. Security teams need to model runner privilege as a production-grade NHI problem.

Secret masking is not a substitute for secret hygiene: Redaction controls only help if exposed values stay in expected formats. Once attackers can transform and print secrets, the log stream becomes an access channel rather than an audit trail. The practical conclusion is that credential minimisation and ephemeral issuance matter more than trying to sanitise every possible output path.

Identity blast radius is the right lens for CI/CD compromise: A single compromised action can touch repositories, cloud services, and package registries because build identities are often reused across many systems. That is a governance failure in credential scope and lifecycle, not just a detection problem. The field needs to stop treating CI/CD compromise as isolated pipeline risk and start treating it as cross-platform identity exposure.

Immutable provenance should be paired with constrained execution scope: Even when code integrity is improved, the runner still needs strict task-scoped permissions and short-lived credentials. The article shows that secure provenance and narrow authorisation solve different halves of the same problem. Practitioners should govern both the source of code and the privileges of the identity that executes it.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Identity blast radius is the useful concept here: A compromised workflow identity can move from source control into cloud access, package publishing, and repository modification if its permissions are shared too broadly. That means CI/CD governance has to be designed around what the runner can reach, not just how the job starts. The build system is an identity domain with its own lifecycle and revocation problem.

GitHub Actions style attacks also show why ephemeral credentials matter more than masking after the fact. Once a runner can read tokens from memory, the security boundary has already shifted from authentication to containment, and log hygiene becomes only a partial backstop. Teams should expect workflow identity to be targeted anywhere build privileges overlap with production access.

For practitioners

• Pin workflow dependencies to immutable references Replace mutable version tags with commit SHAs for third-party actions so the workflow executes a known code state instead of a moving target.
• Scope runner permissions to the minimum workflow need Limit GITHUB_TOKEN scopes, cloud role permissions, and repository write access so a compromised action cannot move laterally through the build chain.
• Eliminate long-lived secrets from CI/CD Use short-lived tokens and OIDC federation where possible so runners do not carry reusable cloud credentials that can be harvested from memory or logs.
• Treat workflow logs as sensitive output Block secret-bearing command output, review log retention, and verify that masking cannot be bypassed by simple encoding or transformation.
• Review third-party action trust chains Inventory every external action used in high-privilege pipelines and validate who can publish, retag, or update it before it reaches production workflows.

Key takeaways

• This incident shows that a build pipeline can become a privileged identity surface when external actions are trusted through mutable references.
• The attack affected over 23,000 repositories and demonstrated how a single compromised workflow can expose credentials across multiple downstream systems.
• Immutable action references, tighter runner permissions, and short-lived credentials are the controls that most directly limit this kind of exposure.

Key terms

• Immutable Workflow Reference: A workflow reference that points to a fixed, unchangeable code revision rather than a mutable tag. This reduces the chance that a trusted dependency can be silently retargeted after approval, but it still needs permission scoping and secret governance to be effective.
• 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.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of how the malicious GitHub Action used retagging to preserve execution across dependent workflows
• The full incident workflow showing how memory scanning, log exposure, and credential reuse chained together
• Practical remediation details for GitHub Actions runners, workflow permissions, and secret-handling controls
• The article’s FAQs on immutable SHAs, OIDC, and least-privilege token scopes

👉 Unosecur's full blog covers the attack chain, exposed credentials, and workflow-level remediation steps

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.