It is expected that the GitHub-owned clients, such as GitHub Mobile and GitHub CLI, include both the OAuth client ID and OAuth secret. GitHub for mobile uses Universal/Deep links (github://) which helps reduce the risk of any issue presented here by binding the OAuth callback directly to the GitHub mobile application.

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. Simply demonstrating that GitHub is running a known vulnerable version is not sufficient, the submission must demonstrate an actual impact of exploitation like disclosing private data.

Vulnerabilities that are due to a vulnerability in an upstream dependency are out of scope and should instead be disclosed to the upstream maintainers. We may make exceptions for vulnerabilities that have a substantial impact to our production environment and customer data, however, issues should still be directed to the maintainers of the dependency upstream first.

Several GitHub owned sites are created using a static site generator and hosted on GitHub Pages. These applications do not contain any sensitive user information or authenticated sessions. As a result, this does not present a security risk.

Vulnerabilities that require local system access are out of scope and ineligible for bounty across all services.

Network-level and volumetric denial of service attacks (e.g., DDoS, traffic flooding) are not allowed and are ineligible for reward. We have mitigation plans in place for these types of attacks. Application-layer denial of service vulnerabilities (e.g., ReDoS, logic bombs) are eligible — please see our rules for guidelines on how to research these responsibly.

Typosquatting on domains similar to GitHub official domains are out of scope and ineligible for bounty. If you would like to report a domain, please report to our support team.

Most open source repositories are outside the scope of our bug bounty program. The repository’s SECURITY.md describes the best avenue for reporting vulnerabilities in open source projects. Please ensure to submit your report to the place outlined in the file.

The dependency update jobs are designed to execute arbitrary code. Update jobs run in a sandbox designed to execute untrusted code and prevent access to private networked resources or other users’ data. Escaping the sandbox to access private networked resources or other user’s data is a vulnerability and eligible for reward.

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. Secret gists aren’t private. If you send the URL of a secret gist to a friend, they’ll be able to see it. However, if someone you don’t know discovers the URL, they’ll also be able to see your gist. If you need to keep your code away from prying eyes, you may want to create a private repository instead.

It is an intentional design decision to allow root access to the machines running actions to give users greater flexibility and ability to install software for their CI. The VMs that run Actions are not persisted / re-used, and are continually recycled. Additionally, each machine is on its own VNet and should not have network visibility into other user’s running Actions.

Additionally, it’s expected and known behavior that the metadata service is accessible and it should not present a security risk.

If you are able to demonstrate that you can access information from other VMs in the network, that would be eligible for reward.

To prevent accidental disclosure of secrets, GitHub Actions includes a mechanism to sanitize any encrypted secrets that appear in build logs. Our mechanism attempts to match any secrets in common encodings, such as plaintext, base64, etc. It is not designed to prevent users intentionally disclosing secrets in non-standard encodings and is therefore ineligible for reward.

Intentionally misusing CPU, memory or network limits of GitHub Actions is a known issue. We take abuse and spam seriously and have a dedicated team that tracks spammy users. Therefore, this is ineligible for reward.

A GitHub Actions build will intentionally have access to many resources including, but not limited to:

• a metadata service available at https://169.254.169.254
• a job token used to report status back to GitHub.com
• privileged access to the host VM

Access to these resources is expected and not eligible for a reward. However, if these primitives can be abused to access resources of other repositories or users then this would be eligible for reward.

Downloading build artifacts requires read access to a repository. When a user with read access clicks the download button, they will be given a link containing a signed token that is no longer tied to the user session. This is expected behavior and ineligible for reward.

Reports about excessive CPU, memory, disk, or storage consumption within a user’s own codespace are billing or quota concerns, not security vulnerabilities. This includes bypassing disk partition limitations within the codespace VM.

Codespace VMs may have access to cloud metadata services (for example, 169.254.169.254). Network access to and retrieval of metadata from these services within the same codespace VM is expected behavior and not eligible for a reward.

Reports are eligible only if metadata service access can be used to cross tenant boundaries, access another user’s codespace, access GitHub internal infrastructure, or otherwise violate Codespaces isolation guarantees.

Codespaces run user-defined environments configured via dev containers. Vulnerabilities in third-party packages, Docker images, VS Code extensions, or other software—whether pre-installed or added by the user or their dev container configuration—are the responsibility of the upstream maintainer and not eligible for a reward. This includes known CVEs in pre-installed dependencies.

A codespace will intentionally provide its user with elevated access including, but not limited to:

• root access within the container
• access to the Docker socket (docker.sock)
• ability to mount host directories via Docker Compose
• read access to VM-level resources such as /proc

This level of access within a user’s own codespace is expected by design and not eligible for a reward. However, if these capabilities can be used to access another user’s codespace, reach GitHub internal infrastructure, or otherwise cross the codespace’s VM isolation boundary, that would be in scope.

The GitHub Copilot Chat extension and Inline Suggestions from GitHub Copilot in Visual Studio Code are features owned and maintained by Microsoft. Vulnerabilities affecting these features should be reported directly to Microsoft through their Bug Bounty Program.

We are aware of prompt injection techniques (including indirect or “invisible” prompt injection via untrusted content such as issue/PR descriptions, comments, or repository files) that may attempt to influence Copilot output. Reports that only demonstrate that Copilot’s output can be influenced or redirected by untrusted content are not eligible for a reward.

• Prompt injection reports may be eligible only when they demonstrate a concrete security impact such as:
  • Privilege escalation or authorization/policy bypass
  • Cross-tenant / cross-repository data exposure
  • Unauthorized actions occurring without required user confirmation or that bypass enforced authorization, policy, or safety controls.

GitHub Copilot is designed to generate the best code possible given the context it has access to, but it doesn’t test the code it suggests, so the code may not always work or even make sense. GitHub Copilot can only hold a very limited context, so it may not make use of helpful functions defined elsewhere in your project or even in the same file. It may also suggest old or deprecated uses of libraries and languages.

For suggested code, certain languages like Python, JavaScript, TypeScript, and Go might perform better than other programming languages. In addition, when converting comments written in non-English to code, there may be performance disparities when compared to English.

Although Copilot suggestions are not part of the Bug Bounty program, you are welcome to report any vulnerable patterns you identify in code suggestions to copilot-safety@github.com. Our blog has more information about our approach to securing code suggestions.

Any strings suggested by Copilot that resemble tokens are not eligible.

Any Copilot features that are not yet publicly accessible are considered out of scope.

Any Copilot chat conversations that are off topic and not programming-related are not eligible.

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.

Credentials exposed by our users are not in scope for our bounty program. We automatically scan public repositories for leaked credentials, and we strongly encourage developers to enable GitHub Advanced Security Scanning protections on their private repositories to do the same.

Additionally, you can use this REST API to revoke any credentials you discovered without authentication.

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

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.

Access to the GitHub Enterprise Server appliance shell and its containers is expected to include access to sensitive information and credentials that are required to operate local services.

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.

The GitHub Mobile apps do not clear on-screen data when they are backgrounded. This is by design and does not present a security risk.

The GitHub Mobile apps do not attempt to detect jailbreaked devices. This is by design and does not present a security risk.

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 users are responsible for the content hosted on GitHub Pages sites. Any vulnerabilities in user content do not affect the security of GitHub.com or its users. We recommend that you report this issue to the owner of this GitHub Pages site.

Subdomain takeovers on GitHub Pages are a known issue that does not present a significant security risk. We are aware of the risks associated with DNS records pointing to GitHub Pages without an intended repository being configured to use the domain. If you have had your domain taken over, please reach out to Support for help reclaiming it.

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. However, if you are able to demonstrate that you are able to perform malicious actions via the HTML tags, please submit a report, as this may be eligible for bounty.

.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 by reporting it as abuse through our support portal.

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.

It is intentional that invitations sent via email can be claimed with any user account. If you wish to invite a specific GitHub user, that user should be invited directly by username.

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 by contacting our support team 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. However, this is something that we are aware of and are working towards hardening the functionality.

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, such as blocking users or locking conversations on issues/discussions/etc. 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. Being able to access functionality that is not available to underprivileged users is eligible.

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.

There are multiple ways on GitHub.com to determine whether an email address or username is in use. We have accepted this risk to improve our users’ experience.

Redirecting the user to the registered callback URL is part of the OAuth specification, and is therefore expected behavior. It is up to users to know and trust the OAuth app that they are authorizing.

GitHub has a list of supported secret scanning patterns in order to identify secrets. If the scanner is not detecting secrets using the default patterns, we encourage you to create custom patterns for secret scanning.

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.

Code execution requiring social engineering or unlikely user interaction is typically not eligible for rewards.

Vulnerabilities which require local system access, such as local credential storage issues.

By default, commands that modify the package tree, such as npm install, run the pre- and post-install scripts. If you would like to disable this, you can set the --ignore-scripts flag. However, note that general code execution that is achieved when using the --ignore-scripts flag is considered out of scope. As stated in the npm documentation, setting the --ignore-scripts flag to true means that “npm does not run scripts specified in package.json files.” Any code execution that occurs when using the --ignore-scripts flag, other than bypassing the specific intended behavior by successfully executing a pre- or post-install script from a package.json file, is considered ineligible.

Vulnerabilities that are due to a vulnerability in an upstream dependency are out of scope and should instead be disclosed to the upstream maintainers. We may make exceptions for vulnerabilities that we deem to have a substantial impact; however, issues should still be directed to the maintainers of the upstream dependency first.

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

npm users are responsible for vetting the content of packages that they choose to install. However, npm takes its responsibility as steward of the JavaScript ecosystem seriously; therefore, we actively scan for malware in the registry. If you do happen to find a malicious package that has yet to be removed, please contact support.

Infrastructure vulnerabilities such as an outdated version of Transport Layer Security (TLS) or a lack of rate limiting are considered out of scope for this bounty program unless you are able to prove privilege escalation or the ability to use it as part of a larger, more impactful attack.

Architectural nuances prevent us from systematically preventing timing attacks from determining whether a specific package exists. Therefore, timing attacks are considered ineligible.