Ineligible submissions

There are a handful of reports that we consider ineligible, either because the feature is working as intended or we accept the low risk as a security/usability tradeoff:

All Targets GitHub Enterprise Server GitHub Pages GitHub Gist * * GitHub Credentials

All Targets

Use of known-vulnerable software

GitHub has a dedicated team responsible for tracking and remediating the use of known-vulnerable software. Submissions related to GitHub services using known-vulnerable software are only eligible 30 days after public disclosure of a vulnerability. In addition, any submissions related to using known-vulnerable software must show evidence of exploitability.

Including HTML in Markdown content

Many areas of GitHub allow content formatted in GitHub Flavored Markdown. It is intended that these Markdown fields allow a limited subset of HTML, such as <b>, <sup> and <details>. HTML included by users in Markdown fields is filtered for malicious input such as <script>, so this does not present a security risk.

Leaking email addresses via .patch links

.patch links on GitHub show the raw commit diff, similar to git-format-patch, and intentionally show the email address used by the author. The email address shown in .patch links is configured by the user with git-config on their local machine. To hide email addresses from Git operations, such as .patch links, users can set the Keep my email address private and Block command line pushes that expose my email options. More details are available in our About Commit Email Addresses documentation.

Phishing using Unicode homoglyphs or RTLO characters

We are aware of different ways that Unicode - specifically homoglyphs and RTLO characters - can be used to display misleading information to other GitHub users. We consider these low-risk and ineligible for a reward. If you have noticed someone using GitHub for phishing, please let us know.

Email verification policy

Any email address that is not already associated with an account on GitHub may be claimed and this will give commit attribution to the claiming user. While we allow this attribution without requiring email address verification, any disputes around emails on accounts can be resolved by contacting our support team.

Impersonating a user through git email address

Because Git is a distributed version control system, GitHub must use the commit email address to assign attribution. When you push a repository to it may contain one or more commits, some of which you may not have authored. For example, imagine a scenario where you collaborated with a number of people on a git repository before you made your first push of that repository to This push would contain a number of commits from several authors. It would be incorrect to assign all of the commits to the person doing the push, so we use the commit log email addresses to assign attribution on Each subsequent push to GitHub uses this same logic to assign attribution of commit authors.

It’s important to note that impersonating another GitHub user in this fashion doesn’t grant you access to any of their repositories or give you any privileges you didn’t already have. However, GitHub does consider impersonation an account abuse issue that we take very seriously. If someone is wrongfully impersonating you, please let us know and we will investigate the matter and deal with it as quickly as we can. In addition, if you are still concerned about this, you and your team can choose to use Git’s built in options to sign commits with a GPG key (check out the git commit -S command).

DMARC, SPF and DKIM email policy

Our DMARC, SPF and DKIM settings are tuned to balance security against email deliverability concerns. We continue to evaluate our setup and may make this functionality more strict in the future.

Bypassing country restrictions for SMS two-factor authentication

The restriction on which countries are able to configure SMS two-factor authentication is based on SMS delivery reliability. We have removed countries we found to have low delivery success rates to prevent account lockout. Our validation is client-side and bypassing this validation does not present a security risk. Users in countries where SMS is unavailable can use an alternative two-factor authentication method

Vulnerabilities in repositories hosted on GitHub

GitHub users are responsible for the content hosted in their repositories. Any vulnerabilties in user content do not affect the security of or its users. We recommend that you report these vulnerabilities directly to the owner of the repository.

Host header injection

Host header injection reports are ineligible unless it can be shown to cause a specific security issue. We set the Strict-Transport-Security header, use HTTP public key pinning, and are in the browser preload lists which prevent active network attacks that may attempt to inject the header.

Timing attacks which reveal a private repository or user

There are architectural nuances that prevent us from systematically preventing timing attacks from determining if a specific repository exists, or if a specific user is part of a secret team, and are therefore ineligible.

Vulnerabilities caused by out-dated browsers

Vulnerabilities that don’t affect the latest version of modern browsers, such as Chrome, Firefox, Edge and Safari, are ineligible. Vulnerabilities caused by browser extensions are also ineligible.

GitHub Enterprise Server

Vulnerabilities caused by lack of subdomain isolation

Vulnerabilities present in GitHub Enterprise Server when subdomain isolation is disabled. GitHub recommends that all GitHub Enterprise Server installations should have subdomain isolation enabled.

Escalation to the root user via sudo

Administrative SSH access grants sudo to be used to escalate to root permissions. Given this existing level of privilege, local escalation of the administrative account to root permissions is not considered in scope.

Bypassing source code de-obfuscation

GitHub Enterprise Server uses code obfuscation to discourage the modification of the application. We are aware of de-obfuscation techniques that could be used to reveal source code or bypass license restrictions.

GitHub Pages

Vulnerabilities in GitHub Pages hosted content

GitHub users are responsible for the content hosted on GitHub Pages sites. Any vulnerabilities in user content do not affect the security of or its users. We recommend that you report this issue to the owner of this GitHub Pages site.

GitHub Gist

Secret gists are accessible via URL without authentication

If you share the URL of a secret gist, anyone with access to the URL will be able to see it without authentication. This is an intentional feature.


Vulnerabilities in out-of-scope subdomains

Not all subdomains are in-scope for rewards at this time and are therefore ineligible for rewards. A list of out-of-scope subdomains is available in our scope section.


Vulnerabilities in out-of-scope subdomains

Not all subdomains are in-scope for rewards at this time and are therefore ineligible for rewards. A list of out-of-scope subdomains is available in our scope section.

GitHub Credentials

Credentials which have been detected by GitHub's Token Scanning feature

GitHub’s Token Scanning feature automatically detects credentials accidentally committed to repositories for a number of service providers. Credentials for GitHub, Inc resources that have already been found via this feature are ineligible for reward.