GitHub Security Bug Bounty

Software security researchers are increasingly engaging with Internet companies to hunt down vulnerabilities. Our bounty program gives a tip of the hat to these researchers and provides rewards of $30,000 or more for critical vulnerabilities.

If you’ve found a vulnerability, submit it here.

You can find useful information in our rules, scope, targets and FAQ sections.

Happy hacking!


These are the current top 10 bounty hunters based on total points earned across all targets. For the full list of contributors, check out GitHub’s bounty hunters.

1 adob 30,750 pts Aleksandr Dobkin<img src=404 onerror=alert(document.domain)> @adob
2 joernchen 28,500 pts joernchen of Phenoelit @joernchen
3 staaldraad 20,000 pts Etienne Stalmans @staaldraad
4 Cache-Money 16,000 pts Tanner @Cache-Money
5 jkakavas 15,600 pts Ioannis Kakavas @jkakavas
6 kyprizel 14,000 pts kyprizel @kyprizel
7 orangetw 12,500 pts Orange Tsai @orangetw
8 kamilhism 10,200 pts Kamil Hismatullin @kamilhism
9 Vlaaaaaaad 10,000 pts Vlad Ionescu @Vlaaaaaaad
10 vyshakh 10,000 pts Vyshakh Parakkat @vyshakh


Before you start
  • Check the list of bugs that have been classified as ineligible. Submissions which are ineligible will likely be closed as Not Applicable.

  • Check the GitHub Changelog for recently launched features.

  • Never attempt non-technical attacks such as social engineering, phishing, or physical attacks against our employees, users, or infrastructure.

  • When in doubt, contact us at

  • By participating in GitHub’s Bug Bounty program (the “Program”), you acknowledge that you have read and agree to GitHub’s Terms of Service as well as the following:

    • you’re not participating from a country against which the United States has issued export sanctions or other trade restrictions, including Cuba, Iran, North Korea, Sudan, and Syria.

    • your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.

    • you are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments.

    • GitHub reserves the right to terminate or discontinue the Program at its discretion.

    • Only test for vulnerabilities on sites you know to be operated by GitHub and are in-scope. Some sites hosted on subdomains of are operated by third parties and should not be tested.

Legal safe harbor

Your research is covered by the GitHub Bug Bounty Program Legal Safe Harbor policy. In summary:

  • We consider security research and vulnerability disclosure activities conducted consistent with this policy as “authorized” conduct under the Computer Fraud and Abuse Act, the DMCA, and other applicable computer use laws such as Cal. Penal Code 502(c). We waive any potential DMCA claim against you for circumventing the technological measures we have used to protect the applications in this bug bounty program’s scope.

  • We want you to responsibly disclose through our bug bounty program, and don’t want researchers put in fear of legal consequences because of their good faith attempts to comply with our bug bounty policy. We cannot bind any third party, so do not assume this protection extends to any third party. If in doubt, ask us before engaging in any specific action you think might go outside the bounds of our policy.

  • Because both identifying and non-identifying information can put a researcher at risk, we limit what we share with third parties. We may provide non-identifying substantive information from your report to an affected third party, but only after notifying you and receiving a commitment that the third party will not pursue legal action against you. We will only share identifying information (name, email address, phone number, etc.) with a third party if you give your written permission.

  • If your security research as part of the bug bounty program violates certain restrictions in our site policies, the safe harbor terms permit a limited exemption.

Performing your research
  • Do not impact other users with your testing, this includes testing vulnerabilities in repositories or organizations you do not own. If you are attempting to find an authorization bypass, you must use accounts you own.

  • The following are never allowed and are ineligible for reward. We may suspend your GitHub account and ban your IP address for:

    • Performing distributed denial of service (DDoS) or other volumetric attacks
    • Spamming content
    • Large-scale vulnerability scanners, scrapers, or automated tools which produce excessive amounts of traffic.
      • Note: We do allow the use of automated tools so long as they do not produce excessive amounts of traffic. For example, running one nmap scan against one host is allowed, but sending 65,000 requests in two minutes using Burp Suite Intruder is excessive.
  • Researching denial-of-service attacks is allowed and eligible for rewards only if you follow these rules:

    • Research must be performed in organizations or repositories you own
    • Stop immediately if you believe you have affected the availability of our services. Don’t worry about demonstrating the full impact of your vulnerability, GitHub’s security team will be able to determine the impact.
    • There are no limits for researching denial of service vulnerabilities against your own instance of GitHub Enterprise Server
Handling personally identifiable information (PII)
  • Personally identifying information (PII) includes:
    • legal and/or full names
    • names or usernames combined with other identifiers like phone numbers or email addresses
    • health or financial information (including insurance information, social security numbers, etc.)
    • information about political or religious affiliations
    • information about race, ethnicity, sexual orientation, gender, or other identifying information that could be used for discriminatory purposes
  • Do not intentionally access others’ PII. If you suspect a service provides access to PII, limit queries to your own personal information.

  • Report the vulnerability immediately and do not attempt to access any other data. The GitHub Security team will assess the scope and impact of the PII exposure.

  • Limit the amount of data returned from services. For SQL injection, for example, limit the number of rows returned

  • You must delete all your local, stored, or cached copies of data containing PII as soon as possible. We may ask you to sign a certificate of deletion and confidentiality agreement regarding the exact information you accessed. This agreement will not affect your bounty reward.

  • We may ask you for the usernames and IP addresses used during your testing to assess the impact of the vulnerability
Reporting your vulnerability
  • Submissions must include written instructions for reproducing the vulnerability. Submissions without clear reproduction steps or which only include reproduction steps in video form may be ineligible for a reward.

  • When reporting vulnerabilities you must keep all information on HackerOne. Do not post information to video-sharing or pastebin sites. Videos and images can be uploaded directly via HackerOne.

  • For vulnerabilities involving personally identifiable information, please explain the kind of PII you believe is exposed and limit the amount of PII data included in your submissions. For textual information and screenshots, please only include redacted data in your submission.

  • Do not publicly disclose your submission until GitHub has evaluated the impact.

Receiving your award
  • All reward amounts are determined by our severity guidelines.

  • When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).

  • You are free to publish write-ups about your vulnerability and GitHub will not limit what you write. We may pay out your reward before the vulnerability is patched so we may ask that you delay publishing to keep other GitHub users safe.

  • Medium, high, and critical severity issues will be written up on the GitHub Bug Bounty site and included in our leaderboard. We don’t currently post write-ups for low severity vulnerabilities.

  • You may prefer the reward go toward helping others. If you choose so, GitHub will donate your reward to an established 501(c)(3) charitable organization of your choice. GitHub will also match your donation - subject to our discretion. Any rewards that go unclaimed after 12 months will be donated to a charity of GitHub’s choosing.


GitHub runs a number of services but only submissions under the following domains are eligible for rewards. Any GitHub-owned domains not listed below are not in-scope, not eligible for rewards and not covered by our legal safe harbor.

Our main domain hosting user-facing GitHub services. All subdomains under are in-scope except:
  • *
  • *
  • *

Our domain for hosting static assets. All subdomains under are in-scope.

Our domain for hosting and rendering users’ data. All subdomains under are in-scope.

Our domain for hosting employee-facing services. All subdomains under are in-scope except:

Our domain for hosting GitHub’s internal production services. Many of these services are not accessible from outside our internal network. All subdomains under are in-scope.

Our main domain for Semmle and LGTM services All subdomains under are in-scope except:

Our domain for non-production Semmle services All subdomains under are in-scope.

Our domain for serving LGTM downloads. All subdomains under are in-scope.

An instance of LGTM especially for Bug Bounty research. All subdomains under are in-scope.

An instance of LGTM’s backend used for triggering automated tasks. All subdomains under are in-scope.

Severity Guidelines

All bounty submissions are rated by GitHub using a purposefully simple scale. Each vulnerability is unique but the following is a rough guideline we use internally for rating and rewarding submissions:

$20,000 - $30,000+

Critical severity issues present a direct and immediate risk to a broad array of our users or to GitHub itself. They often affect relatively low-level/foundational components in one of our application stacks or infrastructure. For example:

  • arbitrary code/command execution on a GitHub server in our production network.
  • arbitrary SQL queries on the GitHub production database.
  • bypassing the GitHub login process, either password or 2FA.
  • access to sensitive production user data or access to internal production systems.
  • accessing another user’s data in the GitHub Actions service.

The upper bound for critical vulnerabilities, $30,000, is only a guideline and GitHub may reward higher amounts for exceptional reports.

$10,000 - $20,000

High severity issues allow an attacker to read or modify highly sensitive data that they are not authorized to access. They are generally more narrow in scope than critical issues, though they may still grant an attacker extensive access. For example:

  • injecting attacker controlled content into (XSS) which bypasses CSP.
  • bypassing authorization logic to grant a repository collaborator more access than intended.
  • discovering sensitive user or GitHub data in a publicly exposed resource, such as an S3 bucket.
  • gaining access to a non-critical resource that only GitHub employees should be able to reach.
  • using the GitHub Actions repo-scoped GitHub token to access high-risk private content outside of that repository.
  • code execution in a desktop app that requires no user interaction.

$4,000 - $10,000

Medium severity issues allow an attacker to read or modify limited amounts of data that they are not authorized to access. They generally grant access to less sensitive information than high severity issues. For example:

  • disclosing the title of issues in private repositories which should be be inaccessible.
  • injecting attacker controlled content into (XSS) but not bypassing CSP or executing sensitive actions with another user’s session.
  • bypassing CSRF validation for low risk actions, such as starring a repository or unsubscribing from a mailing list.
  • escaping the LGTM worker sandbox to access other user’s data or private networked resources

$617 - $2,000

Low severity issues allow an attacker to access extremely limited amounts of data. They may violate an expectation for how something is intended to work, but it allows nearly no escalation of privilege or ability to trigger unintended behavior by an attacker. For example:

  • signing up arbitrary users for access to an “early access feature” without their consent.
  • creating an issue comment that bypasses our image proxying filter by providing a malformed URL.
  • bypassing community-and-safety features such as locked conversations.
  • bypassing billing & plan restrictions to gain access to paid features.
  • triggering verbose or debug error pages without proof of exploitability or obtaining sensitive information.
  • triggering application exceptions that could affect many GitHub users.
  • triggering XSS or CSRF vulnerabilities in LGTM


In addition to our scope, we want to share a high-level overview of GitHub's services. These list useful information such as documentation and potential research areas: is our main web site. It is our most intricate application with a number of user inputs and access methods. is built on Ruby on Rails and leverages a number of Open Source technologies.

Focus areas

Ineligible submissions


GitHub API

The GitHub API is used by thousands of developers and applications to programatically interact with GitHub data and services. Because so much of the functionality is exposed in the API, security has always been a high priority.

The API is exposed via the original v3 REST interface and the newer v4 GraphQL interface.

Focus areas


GitHub CSP

While content-injection vulnerabilities are already in-scope for our bounty, we also accept bounty reports for novel CSP bypasses affecting, even if they do not include a content-injection vulnerability. Using an intercepting proxy or your browser’s developer tools, experiment with injecting content into the DOM. See if you can execute arbitrary JavaScript or exfiltrate sensitive page contents such as CSRF tokens. Reports of other previously-unknown impacts from content-injection will also be considered.

You can find a discussion of known attacks and our attempts to mitigate them here. Attacks against CSP features not used on, such as script nonces, are not eligible for reward. Vulnerabilities resulting from injection in implausible locations, such as within an element that doesn’t contain user-content, are not eligible for reward.


GitHub Enterprise Server

GitHub Enterprise Server is the on-premise version of GitHub Enterprise. GitHub Enterprise Server shares a code-base with, is built on Ruby on Rails and leverages a number of open source technologies. GitHub Enterprise Server adds a number of features for enterprise infrastructures, including additional authentication backends and clustering options.

You can request a trial of GitHub Enterprise Server for security testing at Code de-obfuscation may be explored to further investigate GitHub Enterprise Server but only for the purpose of the bounty program.

Focus areas

Out of scope

  • is a seperate management portal for GitHub Enterprise Server customers and is not in-scope at this time.
  • Vulnerabilities not present in latest patch release of each non-deprecated version of GitHub Enterprise Server. Major versions of GitHub Enterprise Server are deprecated one year after release. For more information see this list of releases.

Ineligible submissions


GitHub Enterprise Cloud

GitHub Enterprise Cloud is the cloud-hosted version of GitHub Enterprise. It is designed for teams who want advanced authentication and permissions without managing infrastructure. More information about GitHub Enterprise Cloud is available at


GitHub Actions

GitHub Actions allows users to build, test, and deploy code right from GitHub. Action workflows are configured directly in the repository. Self-hosted runners are available for users who require custom hardware configuration or operating systems not offered by GitHub-hosted runners.

Focus areas

  • Each repository in GitHub Actions is isolated from one another. Each job runs in a tenant which only contains resources for that single repository. It should not be possible to access resources from another repository’s job.

  • GitHub Actions have a GitHub token available to them. This token is scoped to the repository from which the workflow is run. This token should not be able to access private content outside of that repository or beyond the permissions listed in the documentation.

  • GitHub Actions provides a mechanism for to store secrets associated with a repository. Upon invocation of a workflow, the secrets are fetched, decrypted, then made accessible to each workflow run.

  • GitHub Apps and OAuth apps should not be able to edit the workflow file in the repository. If an attacker is able to modify the workflow file then they gain access to secrets stored in the repository. This could allow an attacker to escalate their privileges if the application performing the editing has less permissions than the GitHub token accessible within the runtime environment.

  • Official actions in the actions organization

Ineligible submissions


GitHub Pages

GitHub Pages is our static site hosting service designed to host your personal, organization, or project pages directly from a GitHub repository. It uses the Jekyll static site generator and officially supported themes are are developed in the pages-themes organization. GitHub Pages support custom domains and can be secured with HTTPS.

More information is available at

Focus areas

  • Executing arbitrary code during the build process, either via a custom Jekyll theme or vulnerabilities in the command-line Git tools when cloning or checking-out repositories
  • Reading arbitrary files during the build process which discloses sensitive information, for example by misusing path traversal or symbolic links in a custom Jekyll theme

Ineligible submissions


GitHub Gist

GitHub Gist is our service for sharing snippets of code or other text content. Gist is built on Ruby on Rails and leverages a number of Open Source technologies.

Focus areas

Ineligible submissions


GitHub for mobile

Bring GitHub collaboration tools to your small screens with GitHub for mobile.

Focus areas

  • Authentication and credential handling
  • Mobile specific APIs
  • Any protocol handlers, such as github://

Out of scope

  • Push notifications are handled by a third-party system and are not in-scope for the GitHub bounty program.

Ineligible submissions


GitHub Education

GitHub Education offers a variety of tools to help educators and researchers work more effectively inside and outside of the classroom. More details are available at GitHub Classroom is open-source.

Out of scope


GitHub Learning Lab

Get the skills you need without leaving GitHub. GitHub Learning Lab takes you through a series of fun and practical projects, sharing helpful feedback along the way. The app is available at


GitHub Jobs

GitHub Jobs is a great place to attract the best technical talent for your company’s open software development positions.



Dependabot powers GitHub’s automated security fixes. This feature allows GitHub users to automatically update vulnerable dependencies. The core logic of Dependabot is open-source and an overview of the architecture is available.

Focus areas

  • Execution environment breakout attacks, providing access to private networked resources or other users’ data
  • Security issues in dependabot-core

Ineligible submissions



LGTM is a code analysis platform for development teams to identify vulnerabilities early and prevent them from reaching production. It uses CodeQL which works by retrieving source code from version control systems, building it with custom tooling, and creating analysis results.

LGTM uses Docker containers to isolate the build and analysis environment from the rest of the infrastructure. By nature this environment permits arbitrary code execution by any registered user, so the quality of isolation is a critical part of the security model. The public site includes two user types (user and admin user) as well as anonymous access.

Focus areas

  • is a dedicated instance of LGTM for your research. The following classes of vulnerabilities are typically eligible for reward:
    • Cross-Site Scripting (XSS)
    • Cross-Site Request Forgery (CSRF)
    • Missing or broken authentication
    • Breaking out of the LGTM worker sandbox
    • Privilege Escalation

Note: there is no need to request a sign-up, you may self-register accounts.

Out of scope

  • is out of scope and not eligible for bounties.
  • LGTM Enterprise, the on-premise version of LGTM, is currently out of scope and not eligible for bounties.

Ineligible submissions



Subdomains under * provide a number of internal services to GitHub employees. These include our internal blog, helpdesk and bastion access to our internal network.

Focus areas

  • Authentication bypasses allowing access to * services.
  • Subdomain takeovers under *

Ineligible submissions



Subdomains under * run services for our internal production network. Many of these services are not accessible from outside our internal network.

Focus areas

  • Authentication bypasses allowing access to * services.
  • Subdomain takeovers under *

Ineligible submissions


GitHub Credentials

GitHub, Inc. uses a mix of our own physical infrastructure, cloud platforms and third-party services to keep everything running smoothly. Keeping credentials and access tokens secure for these resources is paramount to the security of our employees and users.

Please review our guidance for handling PII before investigating credentials allowing access to GitHub, Inc resources. The reward amount is based on the impact of the leaked credential which will be determined by the GitHub Security team.

Focus areas

  • Credentials allowing access to cloud services, package managers and other resources used by GitHub, Inc employees
  • Credentials accidentally made public in repositories which allow access to GitHub, Inc resources. This does not include credentials exposed by our users and credentials which do not allow access to GitHub, Inc resources.
  • Credentials exposed by third-party services which allow access to GitHub, Inc resources

Ineligible submissions


GitHub Desktop

GitHub Desktop is an open-source Electron-based app for working with your or GitHub Enterprise account. It uses the dugite and dugite-native libraries for performing git operations.

Focus areas

  • Remote code execution via protocol handlers such as x-github-client://
  • Code execution without user interaction when cloning or fetching malicious repositories

Out of scope

  • Code execution requiring social-engineering or unlikely user interaction is typically not eligible for rewards.
  • Vulnerabilities which do not trigger code-execution are out-of-scope and ineligible for reward. We encourage you to open an issue upstream


How is the bounty reward determined?

Our security and development teams take many factors into account when determining a reward. These factors include the complexity of successfully exploiting the vulnerability, the potential exposure, as well as the percentage of impacted users and systems. Sometimes an otherwise critical vulnerability has a very low impact simply because it is mitigated by some other component, e.g. requires user interaction, an obscure web browser, or would need to be combined with another vulnerability that does not currently exist.

Can I submit a video proof-of-concept?

You can certainly attach a video if you believe it will clarify your submission. However, all submissions must also include step-by-step instructions to reproduce the bug. The security team will let you know if we think a video will clarify your report. Submissions which only include video reproduction steps will have a longer response time and we may close your submission as Not Applicable.

Can I submit my report via a third-party or vulnerability broker?

GitHub’s Bug Bounty program is designed to both reward individual researchers and increase the security of all GitHub users. We don’t believe that disclosing GitHub vulnerabilities to third parties achieves either of those goals. As a result, any vulnerabilities that are disclosed to third-party before being submitted to our program are ineligible for rewards.

What are points?

In addition to giving researchers money, we are trying to make this fun. We assign a point value to each vulnerability and list it on this site. The researchers with the most points are listed on our leaderboard. While we use many of the same metrics when determining point value as for dollar value, other non-tangible factors are considered as well. For example, if you provide an awesome writeup of a vulnerability with a functional POC that will be factored in.

What if I do not want my submission published on the bounty website or do not have a GitHub account?

Please still send us your vulnerability! We will only publish your submission after your approval. To be visible within the leaderboard you must provide us with a GitHub username. This allows us to link submissions to a single user and generate your sweet profile page.

Why does severity on HackerOne not match the reward I was given?

We do not always update HackerOne with the assessed severity because we track that information internally. Our payout guidelines and the value of the reward dictate our assessment of severity, not the severity on HackerOne.

Where is your PGP key? I want to use it when I submit a vulnerability.

If you absolutely believe encrypting the message is necessary, please read our instructions and caveats for PGP submissions.