Notifications
Clear all
Topic starter
06/06/2026 2:05 am
TL;DR: A malicious version of tj-actions/changed-files ran for nearly 24 hours and put roughly 23,000 repositories at risk by leaking CI/CD secrets into workflow logs, according to Oasis Security. The breach shows that ephemeral build automation still depends on brittle trust assumptions around NHI credentials, commit integrity, and secret visibility.
NHIMG editorial — based on content published by Oasis Security covering the tj-actions/changed-files GitHub Actions vulnerability: 3rd party vulnerability in CI/CD pipelines
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full analysis
Oasis Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact malicious code path inside tj-actions/changed-files and how it wrote leaked material into workflow logs.
- The memory-dump technique used against Runner.Worker processes and the pattern match that surfaced secret values.
- The timeline of the affected window, including when repositories were at risk and how the malicious version was fixed.
- The vendor's response guidance for detecting exposure, correlating secrets to identities, and rotating affected credentials without breaking services.
👉 Read Oasis Security's analysis of the tj-actions/changed-files GitHub Actions breach →
tj-actions/changed-files breach: what CI/CD teams need to act on?
Explore further
06/06/2026 3:33 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: tj-actions/changed-files breach exposed CI/CD secret trust gaps
