GitHub’s Bug Bounty Program: A Year of Records and Refinements

Since 2014, GitHub has leaned on external security researchers to strengthen its software development lifecycle. Seven years in, the GitHub Security Bug Bounty Program has evolved from an experiment into a critical, mature component of how the company ships secure products. The past year—February 2020 to February 2021—was the busiest and most productive in the program’s history, both in volume of reports and in the sophistication of vulnerabilities disclosed.

Busiest Year Yet

The numbers from the last 12 months tell a clear story of growth. The program handled more submissions than in any previous year, yet managed to maintain—and even improve—response times while doing so.

  • 202 vulnerabilities earned a total of $524,250 in bounty payouts.
  • The program received 1,066 submissions across its public and private tracks.
  • Average time to first response improved by 4 hours from 2019, down to 13 hours.
  • Validated submissions were internally triaged to partner teams within 24 hours on average.
  • Bounties were paid out an average of 24 days after eligible reports were submitted.

These results helped rank GitHub’s program among the top on HackerOne. Since moving to that platform in 2016, GitHub has now paid out a total of $1,552,004 in rewards.

Chaining a Redirect into an Account Takeover

Open redirects are typically dismissed as low-risk vulnerabilities—useful largely for social engineering. But researcher William Bowling (@vakzz) demonstrated that on GitHub.com, such a bug could be chained with the OAuth flow to take over user accounts.

The issue was found in a method used across numerous controllers. It passed unsafe, user-controlled arguments directly to Ruby on Rails' url_for routing method, which was used to generate links and redirect locations. While supplying a JavaScript protocol handler might have enabled cross-site scripting, GitHub.com’s strict Content Security Policy mitigated that avenue. However, the ability to control redirect destinations remained. An attacker could craft a link that appeared to belong to GitHub.com but ultimately led to a malicious site.

Bowling then escalated the impact by pairing the open redirect with the OAuth flow GitHub.com performs for Gist authentication. By using the redirect after a user completed a successful OAuth login, he could leak the user’s OAuth code to an attacker-controlled location. That would have allowed him to log into GitHub Gist as any user who clicked the malicious link.

GitHub’s internal fix relied on existing helper methods—safe_url_for and safe_redirect_to—which filter out untrusted protocols, redirect locations, and other risky arguments. The vulnerable code was refactored to use these safe variants and to eliminate user control of certain url_for arguments. GitHub also added a check to its continuous static analysis tooling to flag any future use of url_for with user-controlled arguments. The company awarded $10,000 for the finding, which is documented in detail on William’s blog.

Streamlining CVE Issuance

Last year marked GitHub’s first full year as a CVE Number Authority (CNA) with MITRE, a status it earned with assistance from the research community. Becoming a CNA lets GitHub clearly communicate fixes for GitHub Enterprise Server directly to customers, making it easier for administrators to identify at-risk instances and prioritize upgrades. it also means that researchers who report vulnerabilities through the bounty program get official credit in the CVE record.

Behind the scenes, GitHub has formalized its internal processes to support this. The workflow is now largely automated and standardized:

  • A chat-op initiates a new pull request based on an internal vulnerability tracking issue.
  • A Product Security Engineering team member fills in a Markdown template with details such as description, category, severity, and affected versions.
  • Engineering and security teams review the entry and provide feedback directly in the pull request.
  • A GitHub Action converts the finalized writeup into the JSON format MITRE requires and adds it to the CVEProject/cvelist repository.

In the first year of this process, GitHub published three CVEs for GitHub Enterprise Server. In 2021 alone, the workflow has already produced seven additional advisories, suggesting the cadence will only increase.

The Private Program Gets Results

While the public bounty program captures attention, GitHub continues to run private programs for beta and pre-release products. These early interventions help the company identify architectural risks before features are broadly deployed. In 2020, three efforts stood out.

GitHub Pages Visibility Restrictions

GitHub Pages has historically published sites to the public internet the moment they were created. A new feature allowing users to restrict access to those with repository access required significant architectural changes. To validate the implementation, GitHub gave private bounty researchers early access to the feature in May 2020 while it was still under development.

Two researchers, Robert Chen (@notdeghost) and Philip Papurt (@ginkoid), found a chain of vulnerabilities—including cross-site scripting—that could bypass the visibility setting. GitHub paid $35,000 for their findings, which were tied to a capture-the-flag challenge set up around the feature. The flaws were fixed before launch, and GitHub also implemented architectural hardening to avoid similar classes of bugs in the future.

GitHub Enterprise Server 2.22

GitHub Enterprise Server 2.22 represented a significant milestone: it was the first release built on a new container-based architecture and the first to add GitHub Actions, Packages, and GitHub Advanced Security code scanning as beta features. Given the combination of new functionality and a fundamentally different architecture, GitHub engaged its private researchers to review the release early during the rollout.

Codespaces

In June, GitHub launched a new private program for Codespaces, its cloud-based development environment. The service’s unique architecture brings a distinct set of security considerations. The program is active now, and GitHub is relying on external researchers to validate the security design and implementation of the service before it becomes more widely deployed.

Looking Ahead

Investment in the program is accelerating. In June 2021, GitHub created a dedicated internal team to manage execution and growth of the bug bounty program. Participants can expect faster triage and response as the team finds its footing, along with new initiatives like live hacking events and an expanded slate of private programs.

The company is also hiring. Those interested in the security work behind the scenes—bounty program management, secure design, and security architecture—can find open positions on GitHub’s careers page.