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. Testing that causes an availability issue on production is not permitted. 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 these 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!