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

At a glance

What this is: A malicious tj-actions/changed-files release leaked CI/CD secrets into GitHub Workflow logs and exposed a large pool of repositories to credential theft.

Why it matters: It matters because CI/CD automation often holds the highest-value NHI credentials in the environment, and a single compromised action can turn build systems into secret-exposure channels.

By the numbers:

• For nearly 24 hours the component remained malicious, risking around 23 thousand repositories.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Oasis Security's analysis of the tj-actions/changed-files GitHub Actions breach

Context

The primary issue here is not just a compromised GitHub Action, but a broken CI/CD trust chain. A widely used workflow component can execute inside sensitive pipelines, read process memory, and leak secrets into logs when the integrity of third-party code is assumed rather than verified.

For identity teams, this is an NHI problem first and a software supply chain problem second. CI/CD runners, API tokens, and personal access tokens are non-human identities with standing access to code, cloud, and deployment systems, so one poisoned dependency can create a broad credential-exposure event.

The article's starting position is typical for modern pipelines: convenience has outpaced identity governance, and build automation is now a high-value secret boundary rather than a low-risk plumbing layer.

Key questions

Q: What breaks when a GitHub Actions workflow component is compromised?

A: A compromised workflow component can turn CI/CD into a secret-exposure path because runner processes may hold credentials, tokens, and job data in memory during execution. If logs or memory are readable by attacker-controlled code, the workflow becomes a credential harvesting channel, not just a build step. That is why action integrity and secret minimisation must be governed together.

Q: Why do CI/CD secrets create more risk than many teams expect?

A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.

Q: How do security teams know if workflow secret handling is actually working?

A: Look for three signals: fewer long-lived secrets in workflows, strong inventory of which jobs can access which credentials, and successful use of short-lived federated auth for cloud access. If secrets still appear in runner logs, environment variables, or ungoverned third-party actions, the control is not working as intended.

Q: Who is accountable when a compromised action leaks repository secrets?

A: Accountability usually spans platform engineering, application owners, and identity governance, because the failure crosses code integrity, workflow design, and credential lifecycle. The right question is not who owns the incident alone, but which team owns action trust, which team owns the secret, and which team owns the downstream access it enabled.

Technical breakdown

Compromised GitHub Actions and workflow execution paths

GitHub Actions run in response to repository events and can execute third-party components directly inside CI/CD jobs. In this case, the changed-files action was replaced with malicious code that executed during normal workflow processing. That matters because the runner environment is trusted to handle secrets, which means any action with execution rights can observe variables, read files, and interact with job context. The technical failure is not only code tampering, but the placement of untrusted code inside a privileged execution path.

Practical implication: treat third-party actions as executable supply chain dependencies, not harmless workflow helpers.

How secrets leak from runner memory into logs

The malicious code first decoded a payload, then used a script to inspect Runner.Worker processes and search for secret-shaped data structures in memory. GitHub runner processes can hold job-request data and secret variables during execution, which creates a window where credentials may exist in readable form outside a vault. Once located, the attacker encoded and wrote the data to logs, turning workflow output into a persistence layer for credential theft. This is a classic exposure path in CI/CD: the compromise is not of the vault itself, but of the runtime surface where secrets temporarily exist.

Practical implication: reduce secret residency in runners and assume logs may become an exfiltration channel.

Pinned versions, commit trust, and OIDC as control boundaries

The attack also shows how version tags and bot-like commits can hide malicious change inside routine maintenance. If a workflow trusts floating action references, commit appearance alone becomes an unreliable integrity signal. The article also points to OIDC as a safer authentication pattern because it reduces dependence on reusable long-lived secrets. In governance terms, the issue is not just rotation cadence. It is whether the workflow ever needed a durable secret at all.

Practical implication: combine signed-commit verification, fixed references, and secretless OIDC authentication where possible.

Threat narrative

Attacker objective: The attacker aimed to harvest CI/CD secrets and reuse them for unauthorized access across repository, cloud, and deployment environments.

1. Entry occurred when a popular GitHub Actions component was modified with malicious code and consumed by normal CI/CD workflows.
2. Credential access followed when the payload searched Runner.Worker memory for secret-bearing data structures and extracted readable NHI credentials.
3. Impact came when the stolen material was written to workflow logs, creating secret exposure across affected repositories and downstream systems.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 secrets are identity assets, not build artifacts: This breach worked because workflow credentials were treated as temporary plumbing instead of governed non-human identities. Once an action can read runner context, the boundary between software supply chain risk and identity compromise disappears. The practical conclusion is that build pipelines need the same lifecycle, scope, and visibility discipline applied to other privileged NHIs.

Signed commits are an integrity control, not a secret control: Verifying commit provenance helps detect some tampering, but it does not solve the deeper problem of where secrets exist at runtime. The article itself shows that a malicious payload can pass through trusted workflow execution and still harvest credentials from memory. Practitioners should read this as a control-layer mismatch, not a single-point failure.

Ephemeral execution does not mean ephemeral trust: CI/CD systems often assume that short-lived jobs reduce exposure automatically, but the attacker only needs a narrow window to capture reusable secrets. That is why the governance problem is less about job duration and more about whether any high-value credential must ever be present in the runner at all. Access scope should be reviewed as if the workflow itself were an identity.

Secret sprawl creates a hidden blast radius in automation: The more repositories, workflows, and integrations that touch the same token, the more one compromised component can propagate risk across teams. This is why central inventory, correlation to underlying identities, and offboarding discipline matter in CI/CD pipelines. Without those controls, a single leaked secret becomes a multi-system access bridge.

Secret exposure window: The attack shows that the dangerous period is not just credential lifetime, but the gap between secret exposure and detection. In this case, malicious code persisted long enough to affect thousands of repositories, which is exactly the kind of window NHI governance must shrink. The practitioner takeaway is to design for exposure detection as if every workflow secret can be observed in transit.

From our research:

• 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.
• Another finding from our research shows that only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader view of how these failures compound, see The 52 NHI breaches Report for real-world attack patterns and root-cause analysis.

What this signals

Secret inventory is now a pipeline control, not a nice-to-have governance layer: teams that cannot map which workflows touch which credentials will not be able to contain a similar event quickly. The practical shift is toward identity-centric CI/CD governance, where every workflow secret is tied to an owner, scope, and revocation path.

With 96% of organisations storing secrets outside secrets managers, the pipeline exposure problem is structural rather than exceptional. That means governance programmes need to treat build automation as an identity boundary with explicit controls, not as a tooling detail delegated to developers.

Commit trust and secret trust must be separated: signed code can still carry runtime credential theft if the workflow has access to secrets in memory or logs. Organisations should prepare for tighter action verification, more secretless authentication, and faster downstream revocation as the default operating model.

For practitioners

• Inventory every workflow credential and action dependency Map which repositories use third-party GitHub Actions, which secrets those jobs can read, and which underlying identities the secrets represent. Prioritise the workflows that can reach cloud, deployment, or package-signing privileges.
• Replace reusable secrets with OIDC where workloads allow it Move GitHub workflow authentication to short-lived federated tokens so jobs do not need durable cloud credentials. That reduces the chance that runner memory or logs contain a credential worth stealing.
• Require signed commits and fixed action references Enforce commit-signature verification and pin third-party actions to immutable versions so routine dependency updates cannot silently redirect to malicious code. Pair that with repository rules that block unauthorised workflow changes.
• Rotate exposed credentials in dependency order Start with the most privileged tokens, then work outward through any secrets that shared the same workflow environment. Correlate each secret to the identity it unlocks before rotation so you do not break services accidentally.

Key takeaways

• This breach showed that CI/CD workflows can become credential-exfiltration paths when third-party actions are allowed to run with access to secrets.
• The scale mattered because roughly 23,000 repositories were put at risk during the malicious window, making this a broad governance issue rather than a single-repo incident.
• The control that would have reduced the blast radius is a combination of secretless federation, fixed action references, and rapid identity-linked rotation of exposed credentials.

Key terms

• 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.
• GitHub Action trust chain: A GitHub Action trust chain is the set of dependencies, references, and execution permissions that determine what code runs inside a workflow. When the chain includes third-party actions, its security depends on version integrity, commit provenance, and the secrets available to the runner during execution.
• Runner.Worker process: Runner.Worker is the GitHub Actions worker process that executes jobs and handles job-request data. Because it can contain environment values and secret-related data during a run, it becomes a sensitive runtime boundary that attackers may target if workflow code is compromised.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.

Deepen your knowledge

CI/CD secret governance and workflow trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to reduce exposure in build pipelines, it is a strong fit.

This post draws on content published by Oasis Security covering the tj-actions/changed-files GitHub Actions vulnerability: 3rd party vulnerability in CI/CD pipelines. Read the original.