tj-actions/changed-files breach exposed CI/CD secret trust gaps

At a glance

What this is: This is an analysis of the tj-actions/changed-files compromise, which turned a widely used GitHub Actions dependency into a secret-exfiltration path for CI/CD workflows.

Why it matters: It matters because CI/CD pipelines often hold high-value NHI credentials, and this breach shows how supply chain trust breaks can expose those secrets at scale.

Context

CI/CD pipelines rely on non-human identities such as tokens, secrets, and workflow permissions to move code from commit to build to deployment. When a third-party action is compromised, the pipeline itself becomes the attack surface, not just the repository that called it.

In this case, the compromised tj-actions/changed-files action leaked secrets from GitHub Workflow logs and remained malicious for nearly 24 hours. That is a classic NHI governance problem because the exposed credentials were not human passwords but machine-used secrets tied to automated release processes.

Key questions

Q: What breaks when GitHub Actions workflows are allowed to access secrets without approval?

A: When workflow secret access is not gated, an attacker can turn the CI runner into the exfiltration tool. A malicious workflow can dump secrets, upload them as an artifact, and remove traces before anyone notices. At that point, detection becomes reactive only, and organisations are left rotating credentials after exposure instead of preventing the theft in the first place.

Q: Why do GitHub Actions and GitLab CI/CD create different secrets risks?

A: GitHub Actions tends to fragment secrets across many repositories and environments, while GitLab CI/CD can cascade values through inheritance in ways that are harder to reason about. The risk profile changes because one model multiplies copies and the other multiplies precedence rules. Both require disciplined lifecycle control.

Q: How do security teams know whether action pinning is enough protection?

A: Pinning is only a source-integrity control, so it is insufficient when the runtime environment still has excessive access. If a trusted version can leak secrets once executed, pinning has not solved the real problem. Teams should judge the control by whether it limits secret exposure during job execution, not by whether the workflow looks stable.

Q: When should teams replace long-lived CI/CD secrets with short-lived tokens?

A: They should do so whenever the workflow needs cloud or deployment access that can be issued just for the job and then discarded. Short-lived tokens reduce the blast radius when an action or runner is compromised because there is less reusable credential value left behind. This is especially important for release and deployment pipelines.

Technical breakdown

How a malicious GitHub Action turns workflow trust into secret exposure

GitHub Actions execute predefined steps inside workflow jobs, and those jobs often receive secrets as environment variables or job inputs. In the compromised action, malicious code executed inside the normal workflow path, then wrote exfiltrated material into logs where it could be recovered later. The risk is not the build step itself, but the trust boundary around third-party actions that inherit access to secrets from the calling repository. Once that dependency is poisoned, the workflow’s normal automation becomes the delivery mechanism for credential leakage.

Practical implication: treat third-party actions as part of your access perimeter and review which secrets they can see before they run.

Why CI/CD secret leakage is an NHI governance failure

CI/CD secrets are non-human identities in practice because they authenticate workloads, jobs, and service integrations without a person present. Their security depends on issuance scope, runtime visibility, and revocation speed, not just storage location. This incident shows that a secret can be secure at rest and still be exposed in process memory, job traces, or logs during execution. That makes lifecycle control, secret minimisation, and output hygiene central to the control model, especially when automated jobs fan out across many repositories.

Practical implication: reduce the number of secrets available to each workflow and assume runtime exposure is the real control problem.

Why commit integrity and action pinning are only partial controls

The article points to signed commits and pinned action versions as useful guardrails, but neither solves the underlying trust chain alone. Signed commits increase confidence in source integrity, and pinning can reduce surprise changes, yet both still depend on the maintainer account, tag integrity, and update discipline remaining trustworthy. For pipeline security, these controls are compensating measures, not end-state assurance. They reduce exposure, but they do not remove the need to govern where secrets are available during execution.

Practical implication: combine integrity checks with permission scoping and secret isolation instead of treating pinning as a complete defence.

Threat narrative

Attacker objective: The attacker aimed to harvest CI/CD secrets from workflow environments so those credentials could be reused to compromise repositories, automation, and dependent services.

1. Entry occurred when the threat actor poisoned the tj-actions/changed-files component used by GitHub workflow pipelines, giving malicious code a path into normal CI/CD execution.
2. Credential access followed when the malicious code searched runner memory and job context for secret material, then wrote the recovered values into workflow logs.
3. Impact came when affected repositories exposed CI/CD secrets that could be reused for further automation abuse, account access, or downstream pipeline compromise.

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.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

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

NHI Mgmt Group analysis

CI/CD secret trust debt: This breach exposed how much pipeline security still depends on secrets being present, visible, and trustworthy at exactly the wrong time. GitHub Actions can protect storage and still fail at runtime, because the action itself receives the secrets needed to do its job. The practitioner conclusion is that pipeline governance must treat secret exposure during execution as the primary risk, not an edge case.

Third-party action trust is an identity decision, not a build convenience: A reusable action is not just code reuse, it is delegated execution with inherited access. Once a maintainer or tag is compromised, the calling repository inherits that compromise through the trust chain. The practitioner conclusion is to evaluate every shared action as an identity boundary with access consequences, not as a neutral dependency.

Signed commits do not close the runtime gap: Commit verification improves source integrity, but this incident shows that source integrity and runtime secrecy are different problems. A verified commit can still run in a job with excessive access, and a trusted workflow can still expose secrets to logs or memory. The practitioner conclusion is that commit policy, action pinning, and secret scoping must be designed as separate controls.

Ephemeral build automation still needs lifecycle governance: The compromise remained active long enough to affect thousands of repositories because automated environments scale faster than manual review cycles. That makes lifecycle control around issuance, revocation, and blast-radius limitation essential in CI/CD. The practitioner conclusion is that every pipeline secret needs ownership, scope, and retirement criteria before the next release runs.

GitHub Actions secret leakage is now a governance category, not just an incident pattern: Once workflow logs can become the exfiltration channel, the question shifts from whether a secret is protected in a vault to whether it is ever unnecessarily available to a job. That changes how teams should think about least privilege for automation, because the object being governed is the workflow session itself. The practitioner conclusion is to govern workflow access with the same seriousness applied to privileged service accounts.

What this signals

CI/CD secret exposure should be treated as a workflow design problem: The point is not simply to rotate faster after an incident. Pipelines need fewer secrets available at runtime, tighter action permissions, and stronger separation between build steps that do not need credential access.

Trust boundaries need to move closer to execution: Repository controls alone are not enough when the dependency executing inside the workflow can inherit secret access. Governance has to account for what the job can see, not just what the repo owns.

For practitioners

• Map every workflow secret to a business owner Document which repository, action, or environment can read each secret and assign a human owner for rotation and revocation decisions.
• Restrict third-party action permissions Limit job-level permissions, reduce secret exposure to only the steps that truly need them, and block broad default access to runner context.
• Require signed commits for release paths Enforce commit signing on branches that can trigger build or deployment workflows so repository history cannot be silently rewritten.
• Move high-risk workflows to OIDC-based access Replace long-lived cloud and deployment secrets where possible with short-lived tokens issued at job start and discarded when the workflow ends.
• Audit logs for secret exposure paths Search workflow logs, runner output, and job traces for secret spill, then rotate any credential that could have been visible to the compromised action.

Key takeaways

• The breach showed that CI/CD pipelines can leak non-human credentials during normal execution when a trusted action is poisoned.
• The risk is not limited to one repository because the same workflow pattern can expose secrets across many automated environments.
• The most effective controls are tighter runtime scoping, stronger dependency integrity checks, and faster secret revocation when exposure is suspected.

Key terms

• GitHub Actions Workflow Orchestration: GitHub Actions workflow orchestration is the controlled process of applying approved workflow patterns across multiple repositories. In practice, it helps teams standardise CI/CD behaviour, reduce drift, and enforce consistent security and operational controls through automated pull requests rather than ad hoc manual copying.
• CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
• Third-Party Action Trust: The trust placed in external workflow components to run inside a pipeline with inherited permissions. This is a governance decision about delegated execution, not just software reuse, because a compromised action can observe, misuse, or expose the secrets available to the calling job.
• Commit signing: Commit signing is the process of attaching a cryptographic signature to a code change so it can be verified later. It is useful only when the signature is tied to a trusted identity and enforced by repository policy, otherwise it becomes weak evidence rather than strong assurance.

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.