Bypassing required reviews using GitHub Actions

Not using GitHub Actions? You’re also vulnerable.

Omer Gil
Omer Gil
Oct 12 · 6 min read


A newly discovered security flaw in GitHub allows leveraging GitHub Actions to bypass the required reviews mechanism and push unreviewed code to a protected branch, potentially allowing malicious code to be used by other users or flow down the pipeline to production.

The risk of a compromised user account

GitHub is the most popular source control management system, serving millions of users and companies who use it to host their codebases. A GitHub organization can include any number of members — from several to hundreds or even thousands of members, with varying permissions. Write permissions are commonly granted to many users, as that is the base permission needed to directly push code to a repo.

Required reviews for merge

To avoid this exact scenario (and for quality considerations, obviously), branch protection rules were created, and are used by nearly all engineering organizations today to provide baseline protection against such attack vectors. For sensitive branches (such as the default one — or any other branch we’d want to protect), we can set rules to limit an account with Write permissions to directly push code to it by requiring the user to create a pull request. Once a pull request is created, it needs to be approved by a preset number of approvers before it can be merged to the target branch.

GitHub Actions

GitHub has evolved significantly since its inception — and continues to add features, products, and tools for code management and shipment. One such tool is GitHub Actions — GitHub’s CI service — which is used to build, test, and deploy GitHub code by building and running workflows from development to production systems.

Why is GitHub Actions relevant to bypassing protected branch configurations?

Our research has exposed a flaw that leverages GitHub Actions to bypass protected branch restrictions reliant on the multiple reviews control.

  1. Any user that can push code to the repo (Write permissions or higher), can create a workflow that runs when code is pushed.
  2. With each workflow run, GitHub creates a unique GitHub token (GITHUB_TOKEN) to use in the workflow to authenticate against the repo. These permissions have a default setting, set in the organization or repository level. This setting allows granting the token with restricted permissions — Read permission on the contents and metadata scopes, or permissive permissions — Read/Write permissions on various scopes, such as contents, packages, and pull requests.
  3. However

Getting to the point

So, what does a typical GitHub organization look like?
It generally has:

  1. GitHub Actions installed by default for all GitHub organizations, on all repositories.
  2. Permission for any user with Write access to run a workflow in the repo.
  • Workflow is configured to run on pull_request events. That includes creations and updates of PRs.
  • Workflow is granted with Write permissions on the pull requests API endpoint.
Workflow code to automatically approve a PR
The PR is successfully approved with “github-actions” as the reviewer, and the code can be merged

PoC video

Report to GitHub

This security issue was reported to GitHub through their bug bounty program. They accepted it, wrote that it’ll be tracked internally until resolved, and approved to publish a write-up.


15/09: Reported to GitHub bug bounty program
15/09 : First response from GitHub
22/09: Triage
22/09: Payout
23/09: Approval for write-up


  • If you’re not using GitHub Actions, disable it for the entire organization or for specific repositories where it’s not required.
  • If GitHub Actions is in use in the organization, you can do one of the following:
    - Require a review approval in pull requests from Code Owners.
    - Increase the required number of approvals to 2 or more.
    - Wait until the issue is resolved by GitHub.

Cider Security

Blog posts from Cider Security’s R&D and leadership teams.