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 have found a vulnerability, submit it here.
You can find useful information in our rules, scope, targets and FAQ sections.
Happy hacking!
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:
For the month of October we’ll be offering an 20% bonus on the highest valid submission for any hackers new to our program, a 10% bonus on the highest valid submission for returning hackers as well as a 5% bonus on reports that include a Nuclei template that we can use to verify fixes! Note: Each hacker can earn atleast one of these bonuses!
Find more details regarding eligibility in our FAQ.
Critical severity issues present a direct and immediate risk to a broad array of our users or to a GitHub product itself. They often affect relatively low-level/foundational components in one of our application stacks or infrastructure. For example:
The upper bound for critical vulnerabilities, $30,000, is only a guideline, and GitHub may reward higher amounts for exceptional reports.
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:
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:
package-lock.jsonLow 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 allow nearly no escalation of privilege or ability to trigger unintended behavior by an attacker. For example:
.npmrc file or from GitHub Enterprise Server being leaked in logsGitHub 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.
In addition to our scope, we want to share a high-level overview of GitHub's services:
Check the list of domains that are in scope for the Bug Bounty program and the list of targets for useful information for getting started.
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 [email protected].
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 are not currently a GitHub employee or contractor, were not a GitHub employee or contractor within six months prior to submission, and you did not collaborate on your submission with anyone who was.
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 GitHub.com are operated by third parties and should not be tested.
We cannot reward any individual on any U.S. sanctions list, or any individual residing in any U.S.-sanctioned country or region. For more information, please see https://www.hackerone.com/disclosure-guidelines.
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 coordinate disclosure 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.
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.
We recommend adding your HackerOne @wearehackerone.com email address to any GitHub account that you use to perform security research and testing. If you use multiple GitHub accounts for testing, you can use aliases of your HackerOne email address. Clearly identifying accounts that are associated with bounty research helps our teams to differentiate between possibly malicious activity and that of researchers involved in our Bug Bounty program. Please note that adding your HackerOne email address does not provide any exemptions to our Terms of Service or permit you to act beyond our bounty rules and scope.
The following are never allowed and are ineligible for reward. We may suspend your GitHub account and ban your IP address for:
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:
https://github.com)
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.
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.
During the course of an investigation, it may take time to resolve the issue you have reported. We ask that you refrain from publicly disclosing details regarding an issue you’ve reported until the fix has been publicly made available.
All reward amounts are determined by our severity guidelines.
In addition to the bounty reward, some reports will also receive a coupon code that can be redeemed for swag items at the GitHub Bug Bounty Merch Shop. For more information about the store, please visit the shop’s FAQ page.
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.
GitHub is a CVE Numbering Authority (CNA) for GitHub Enterprise Server. Eligible Bug Bounty submissions that affect GitHub Enterprise Server may be assigned CVEs. These CVEs will be shared with submitters via HackerOne and listed in the GitHub Enterprise Server release notes.
If you would prefer to donate your bounty reward to an established 501(c)(3) charitable organization, GitHub will match your donation. If the bounty has already been processed into your account, it can no longer be donated through HackerOne and is no longer eligible for matching donations. To reduce the likelihood of a bounty being processed before it can be donated, we recommend changing your payment preferences to monthly in your account settings. To donate your reward and have it matched, submit a support ticket to HackerOne with the following information:
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., it requires user interaction, it relies on an obscure web browser, or it would need to be combined with another vulnerability that does not currently exist. Our teams use our documented severity guidelines to determine the bounty reward amounts rather than correlating with CVSS ratings. Additionally, at least two GitHub security engineers agree on the severity and amount before a payout is made.
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.
You may get a response that appears to be from a bot. The bot does some work for us, but only when we tell it to. We “do our own stunts” at GitHub Security. An application security engineer at GitHub triages each submission. In most cases, we use the bot to automate messaging and other tasks for us. Rest assured, a human did look at your submission.
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.
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.
If you absolutely believe encrypting the message is necessary, please read our instructions and caveats for PGP submissions.
As noted in the performing your research section, denial of service research is best done on your own instance of GHES. Causing an availability issue is simply not helpful. We are only interested in denial of service issues at the application layer (logic bombs, ReDoS, etc.). Volumetric attack submissions are not eligible for rewards and we may suspend your GitHub account or temporarily ban your IP address.
We’re stoked to hear you’d like to become a Hacktocat! In order to be eligible to receive an invitation, you must earn at least $20,000 in our program and have submitted at least 2 reports over the last 2 years. Please note that meeting this criteria does not guarantee an invitation. We reserve the right to extend invitations at our discretion. We review eligibility and make decisions on candidates on a quarterly basis.
Our VIP Hacktocats gain access to a Slack channel with Hubbers, exclusive Hacktocat swag, access to beta features, and more!
We’re offering an 20% bonus to any first time submitter to our program on their highest severity for a valid submission to our program. In order to be eligible, you must have not sent in a valid submission to our program in the past.
We’re also offering a 10% bonus to any returning submitters on their highest severity for a valid submission to our program. Note: Each hacker can only earn one of the two bonuses mentioned above.
In order to be eligible for the 5% bonus for submission of a Nuclei template, your submitted template must:
These bonuses are available at GitHub’s sole discretion, and additional circumstances around the complexity of reports may be considered when evaluating the requirements detailed above.