3 min read

Attackers Can Bypass GitHub Required Reviewers to Submit Malicious Code

Featured Image

Update: a few weeks after this publication, GitHub decided to fix the issue and employed the mitigation we recommended to them in our initial report. The mitigations section of this post was updated accordingly; read it to make sure your repositories are well-configured and safe from this kind of attack.

Code reviews are an essential security guardrail, but GitHub’s required code reviewers' settings might be giving you a false sense of security – they can easily be bypassed by any collaborator with reviewer permissions.

See how an attacker can use a compromised account to submit malicious code and merge it into your repository’s main branch while bypassing code review restrictions in this post.

 

TL;DR

  • GitHub’s required reviewers capability can be bypassed if currently using this setting to require at least one code review before merging code.

  • Any code reviewer reviewing code can simply submit malicious code on pull requests during the review process and merge that code to the main branch without review.

  • GitHub does not currently provide users the ability to eliminate this risk directly.

Even if you followed every agile development best practice perfectly, there are still risks in agile software development. Agile has proven that it offers more benefits than drawbacks, so it’s important to understand the potential security risks so that you can mitigate them ahead of time.

 

What are Required Reviewers?

A typical development workflow looks like the following:

  1. The developer diverges from the repository’s main development branch

  2. Then the developer adds/deletes/modifies the code as needed.

  3. Finally, a second person must review and approve the changes before that code can be merged back to the main branch.

securing code review in the software development lifecycle

To support this common workflow, GitHub introduced the concept of Protected Branches. A protected branch is a branch that contains restrictions on who can modify it and how.

For example, the below configuration enforces any developer who wants to push code to the main branch to create a pull request and also get approval from a second, authorized person to approve pull requests.

securing default main branch

branch protection settings to secure the main branch

 

(A complete list of Branch Protection rules can be found in GitHub’s documentation.)

For obvious reasons, GitHub doesn’t allow developers to authorize their own pull requests – otherwise, there’d be no point in requiring a “required approval.”

However, I’ve discovered that there is an easy method a developer can use to authorize their own pull requests: pull request hijacking.

 

What is Pull Request Hijacking?

Any user authorized to approve pull requests can modify existing pull requests of other users as desired. After modifying the existing pull requests, they can approve and merge the code without requiring approval. This works because the original pull request was opened by another user (i.e., “User A”), and GitHub doesn't recognize that a different user (i.e., “User B”) modified it.

You can test this yourself:

  1. Find an open pull request.

  2. Modify it or even replace the entire branch content

  3. Approve your own modifications

  4. Bypass required approvals for your modified code

HubSpot Video

 

 

Responsible Disclosure: GitHub Response

When disclosing pull request hijacking to GitHub, they responded that GitHub is working as intended in this scenario.

“This is an intentional design decision and is working as expected. We may make this functionality more strict in the future, but don't have anything to announce right now. As a result, this is not eligible for reward under the Bug Bounty program.” -GitHub

We believe that GitHub didn’t fix this issue because the resulting experience might be too restrictive for modern development teams. There are many frequent and harmless cases in which developers collaborate on the same branch. For example, if I fixed a small typo when reviewing another developer's code, it makes some sense that I should also be allowed to go ahead and push that code.

 

How to Protect Yourself From Pull Request Hijacking

The following defensive techniques will protect your business from malicious code submissions during a pull request hijack attempt. In addition to these two techniques, you can also lower the risk of malicious code in various ways, like strengthening authentication requirements for developers that are also reviewers and practicing the least privileges in relation to your GitHub organization.

 

New: Require Approval For The Most Recent Pusher

This mitigation measure was implemented after the initial publication of the blog. When activated, it ensures that all changes made to the code are reviewed by another person before being merged. This ensures that any updates to the code are approved, even if the original pull request was modified by someone else.

 

Require At Least Two Reviewers

Configure GitHub to require more than one reviewer. This way, even if an existing pull request is modified and approved by the same user, it would still need a review from an additional person. You can configure this with your GitHub settings, as pictured below.

improve github code review security by requiring 2 reviewers
 
 

Restrict Who Can Push To Matching Branches

GitHub allows you to create a “personal branch” pattern for each developer that no other developer could modify (pictured below).

example branch name pattern aligning to developer specific branch 
secure settings for branch naming protection strategy
 
In this example, if my branch name pattern is "noam/*." I can configure that only Noam can push to this branch. Due to this, a different developer reviewing Noam’s code cannot hijack Noam’s branch to submit malicious code.
 
Legit Security Can Help

A pre-requisite to hardening your GitHub required reviewer configurations is to have visibility into your development pipelines, know where you are using GitHub, whether or not you are requiring code reviews, and whether you have stale or inactive accounts with reviewer permissions. Legit Security can provide visibility and answers to these questions in minutes. In addition, Legit helps you holistically assess security and compliance risks in your development pipelines across other SCMs and also other developer systems like build servers and artifact registries. Learn more about Legit by visiting our platform page or booking a demo with us today.

Related Blogs

GitHub Codespaces Security Best Practices

When GitHub released Codespaces last year it was touted as their best release since GitHub Actions. If you’re using Codespaces or thinking about it,...

Read More

The Open Source Community And Its Critical Role in Software Supply Chain Security

As we head to the Open Source Summit conference next week, we wanted to discuss our contributions to the open source community, why we invest so much...

Read More

Vulnerable GitHub Actions Workflows Part 2: Actions That Open the Door to CI/CD Pipeline Attacks

In this blog post, we’ll explore a bug we’ve found in a popular third-party action and how in some cases it could lead to your SDLC pipeline being...

Read More