Recommended Free Tools
GitHub Actions was a prominent supply-chain attack surface in 2025, including in the serious tj-actions/changed-files compromise. But available figures do not establish that Actions-specific attacks increased year over year: the reported rise in supply-chain attacks covers software ecosystems broadly, not GitHub Actions alone.
What happened in the tj-actions/changed-files compromise?
In March 2025, an attacker compromised tj-actions/changed-files, a third-party GitHub Action used in other projects’ automated workflows. Palo Alto Networks Unit 42’s investigation, updated April 2, 2025, describes an attacker with a write-capable token introducing malicious code through a repository and dependency chain, then changing tags to point to the malicious commit.
That matters because workflows often trust external Actions, while their runners may have access to credentials. When affected workflows ran the compromised Action, credentials in runner memory could be exposed in workflow logs. Unit 42 traced the chain through reviewdog/action-setup and related Actions.
The UAE Cyber Security Council’s March 2025 advisory identifies the vulnerability as CVE-2025-30066 and assigns it a CVSS score of 8.6. It reports that the Action was used in more than 23,000 repositories and names risks to AWS credentials, GitHub Personal Access Tokens, npm tokens, and private RSA keys. That reported usage is not a count of repositories confirmed compromised.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Did GitHub Actions attacks actually increase in 2025?
The reviewed sources do not provide comparable annual counts of GitHub Actions supply-chain compromises for both 2024 and 2025. So the evidence supports saying the risk drew attention and that significant incidents occurred—not claiming a measured year-over-year increase in Actions-specific attacks.
Red Hat’s Product Security Risk Report 2025 records 137 publicly reported software supply-chain attacks, a 54% year-over-year increase. It also says npm accounted for 40% of attacks and that the proportion affecting other ecosystems, including GitHub, decreased. Those are cross-ecosystem figures; they do not show that attacks targeting GitHub Actions rose.
GitHub’s April 2026 supply-chain guidance describes Actions workflows as a common starting point in open-source supply-chain attacks, which may seek to steal secrets, publish malicious packages, or reach more projects. That later guidance signals continuing concern, but it is not a count of incidents in 2025.
How can a compromised Action put a project at risk?
A workflow can run code maintained outside your repository with privileges granted to the job. If an attacker changes what that code does—or redirects a mutable version tag to malicious code—the workflow may execute the attacker’s code in an environment that holds credentials. Those credentials can enable further access or unauthorized publishing.
GitHub describes supply-chain attacks as chains that can involve initial access, privilege escalation, and distribution. A single defense cannot block every link, so reduce the chance of running malicious code, limit what a workflow can reach, and watch for unexpected activity.
How do you secure GitHub Actions against supply-chain attacks?
Pin dependencies and review workflow changes
- Pin third-party Actions to full-length commit SHAs rather than mutable version tags. Review changes to those references so an unexpected update does not silently change the code a workflow runs.
- Use CodeQL to review workflow implementations for security issues. GitHub says CodeQL is available free for public repositories.
Limit permissions and credential exposure
- Give each workflow job only the permissions it needs, and avoid making valuable credentials available to jobs that do not require them.
- Where the cloud provider, package registry, or service supports it, prefer OIDC workload identity over long-lived stored credentials.
Protect workflows from untrusted input
- Avoid
pull_request_targetwhen untrusted pull-request content could run with access to base-repository privileges or secrets. - Treat user-supplied content used in workflow scripts as untrusted and guard against script injection.
Watch runtime behavior
Monitor workflow behavior and investigate unexpected outbound connections. In a July 2026 update, GitHub described an Actions network firewall in technical preview that logged outbound traffic; at that time, egress restrictions were described as future work. This is a visibility measure, not evidence that all outbound traffic was already blocked.
Rank #4
What should you do if a workflow may have exposed secrets?
- Identify workflow runs that used the affected Action or dependency, and determine which credentials those runs could access.
- Revoke or rotate credentials that may have been exposed. Review the relevant secret stores and service accounts as part of that response.
- Check downstream activity, including repository changes and package publishing, for actions you did not authorize.
The UAE Cyber Security Council’s advisory emphasizes reviewing secrets and remediation. The exact scope of a response depends on the credentials available to the affected workflows and what those credentials could access.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
