GitHub.com is our main web site. It is our most intricate application with a number of user inputs and access methods. GitHub.com is built on Ruby on Rails and leverages a number of Open Source technologies.
ssrf-target.iad.github.net to test out SSRF attacks.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.
.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.
We are aware of different ways that Unicode - specifically homoglyphs, RTLO, and non-printable 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.
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.
Because Git is a distributed version control system, GitHub must use the commit email address to assign attribution. When you push a repository to GitHub.com 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 GitHub.com. 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 GitHub.com. 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).
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.
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
GitHub users are responsible for the content hosted in their repositories. Any vulnerabilities in user content do not affect the security of GitHub.com or its users. We recommend that you report these vulnerabilities directly to the owner of the repository.
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.
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.
Enabling 2FA does not imply that an account may have been compromised, and as a result, we do not reset all existing sessions. If a user changes/resets their password GitHub will reset all existing sessions.
Enabling 2FA without a verified email is allowed. While this could prevent someone from using that email address, we consider this a spam and abuse issue.
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.
Our “Camo” system is used to proxy images included in Markdown fields via githubusercontent.com. We rely on the isolation of githubusercontent.com and the fact that we don’t send any cookies to that domain. These images are untrusted and we intentionally do not attempt to modify or filter the response. Additionally, we deploy our image proxy on its own network segment to prevent it from making requests to internal IP addresses. We don’t consider the ability to make requests to external services a security risk, as an attacker can perform this in many other ways without using GitHub’s image proxy.
We use Sudo mode to ensure legitimate users are taking certain high risk actions. If we have not included sudo mode on an endpoint, we have likely accepted its risk and most submissions will be ineligible.
GitHub employs a number of community and safety features. In most cases, bypasses of these features via some edge case will not result in a bounty reward unless there is a privacy (confidentiality) breach. For example, bypassing the 24 hour interaction limit at 23 hours and 10 minutes will be ineligible. However, if you are able to bypass controls and reveal another user’s private email address, that would be eligible.
Submissions related to archived repos that do not demonstrate the ability to change the actual content in the repo (e.g. adding/removing collaborators, modifying some repo settings) will be ineligible. The same for submissions that do not demonstrate the ability to change ownership or the actual archived status.
Some features may be disabled on GitHub in the UI and that ability (to disable) is more of a convenience than a hard security boundary. Projects and wikis are two examples of this. Accessing those disabled features through the API or some other technique are not eligible for a bounty reward.
As stated elsewhere, submissions around volumetric DoS attacks are not in the scope of our bounty program. Submissions citing lack of rate limiting will be treated similarly. We generally consider such activity spammy or abusive behavior, and have a dedicated team for addressing such issues.