GitHub Actions update: Helping maintainers combat bad actors

Actions abuse: new safeguards for pull requests from forks

GitHub Actions has become a core part of many development workflows, but its popularity has also attracted bad actors. The recent rise in cryptocurrency prices has led to a surge in targeted abuse across CI providers, and GitHub has been fighting cryptomining on Actions since the beginning. As the value of coins has climbed, so has the number of abusers, costing the team thousands of hours in mitigation efforts.

One particularly damaging vector has been pull requests from forks. Attackers submit PRs that run mining code on upstream repositories, which can cause legitimate maintainers to be flagged or blocked due to the abusive activity. GitHub is rolling out two changes to how Actions handles PRs from public forks to address this.

Targeting enforcement at the source

The first change is to how GitHub assesses reputation on Actions. When GitHub determines a run to be abusive or against its usage terms, enforcement will now be directed at the account hosting the fork, not the account associated with the upstream repository. The intent is to prevent maintainer accounts from being blocked because of bad actors exploiting their repos.

Manual approval for first-time contributors

The second change introduces a manual approval step. Pull requests from first-time contributors will now require approval from a repository collaborator with write access before any Actions workflows run. When a first-time contributor opens a PR, they will see a notice that a maintainer must approve their workflow before it executes.

Maintainers viewing such a PR will see an “Approve and run” button in the merge box. Once a collaborator with write access approves, the workflows run for that commit only. If the contributor pushes a new commit, a fresh approval is required.

GitHub says this step strikes a balance between manual review and automated workflows, based on conversations with maintainers. It is the default setting, and there is currently no opt-out, though GitHub plans to add additional settings for more flexibility. The company is inviting feedback from affected maintainers and points to its docs for more details on approving workflow runs from public forks.