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 TargetsIt is expected that GitHub-owned clients, such as GitHub Mobile and GitHub CLI, include both the OAuth client ID and OAuth secret. These are public clients, and a public client cannot hold a secret. Recovering one by unpacking an app, reading a binary, or watching traffic is not by itself a vulnerability, and a report that stops there is not eligible.
A working chain that turns the secret into access to an account someone else owns is eligible, and we have rewarded reports of that kind. If you can intercept the OAuth callback from another application on the device and obtain a token for an account you do not control, we want to see it. Tell us the platform and the exact redirect target you intercepted, because a custom URL scheme and a verified Universal Link or App Link do not give the same guarantees.
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.
Reports that you can cause a cached object to be evicted from one of our CDN edges are ineligible. Eviction does not change what we serve. The next request fetches the same content from origin and caches it again, so the result is a cache miss and some additional origin traffic, which our infrastructure is built to absorb. This includes reports where the impact is framed as denial of service.
Cache poisoning is a different finding and is eligible. If you can make a cache serve content you control to another user, or return one user’s private content to another, that crosses a security boundary and we want the report. The distinction is whether you are removing a cached copy or replacing it.
When you delete a file, delete a repository, change a repository from public to private, remove a member from an organisation, or replace an avatar, the original content can remain reachable from our caches and CDNs for a short period afterwards. We have received this report many times, against raw file content, Git LFS objects, rendered notebooks, avatars, link previews, release downloads and gists.
Caches expire rather than being erased everywhere at the moment you make a change, so a copy that was public a moment ago can still be served for a short window. Treat anything that has been public as public. Once content has been served we cannot guarantee that every cached copy of it disappears the instant you change your mind.
Reports that a recently deleted or newly private object is briefly still served are ineligible, including reports that rely on cache status shown in response headers.
Content that was public stays public. Replacing or deleting an avatar, a release asset, a gist or a file that anyone could already fetch does not make the old copy private, so a cached copy of it still being reachable is not an exposure.
It is eligible, and we want the report, if you can reach content that was never public. Where content has been made private, it is eligible if it remains reachable substantially beyond normal cache expiry. If you can retrieve private repository content without a valid, unexpired signed URL, that is a finding regardless of how it got into the cache.
Git is designed to run code that lives in a repository. Hooks, clean and smudge filters, and core.hooksPath all execute by design, and a repository’s local configuration deliberately takes precedence over the global and system files. Demonstrating that in a repository you created yourself is not a finding, and neither is a chain where the victim has to run a git config command that the attacker wrote into a README.
Two details are worth checking before you write one of these up. .git/hooks and .git/config are not copied by git clone, so an attacker cannot plant either of them in somebody else’s working copy that way. And hooks in the default .git/hooks directory run whether or not core.hooksPath is set, so if your proof of concept puts them there, the configuration change is not what made the code run.
What may be eligible is one of our clients doing something unsafe with repository content on its own. We have rewarded a repository name being interpolated into a shell command, a recursive clone reaching a submodule the user never asked for, an artifact extraction that overwrote .git/config, and a configuration file that was read before the trust prompt meant to gate it. Cloning a repository, opening it in a client, or checking out a branch does not by itself make a chain eligible. The report must show the client crossing a security boundary beyond the behavior the user authorized and the product is designed to perform. Following setup instructions the attacker put in a README is not eligible.
Viewing an issue or pull request, cloning or opening a repository, checking out a branch, and reviewing a contribution neither automatically qualifies nor disqualifies a report. Eligibility depends on the specific product, its security model, the warnings or prompts shown, what the action inherently authorizes, and whether GitHub or a GitHub client crosses a security boundary beyond that authorization.
Following instructions supplied by the attacker is different. Reports are ineligible when the chain requires the victim to copy and paste a command into a terminal or developer console, run a script or executable from the attacker, change a security setting, install an extension, grant additional permissions, or approve a warning that explains the risk. In those cases the user is executing or authorizing the attack rather than the product crossing a security boundary.
Describe every required user action exactly. Replacing “the victim pastes and runs my command” with “the victim interacts with a malicious repository” does not make the interaction a vulnerability.
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.
This is one of the most common reasons we close a report. Only the applications and domains listed in our scope are eligible, and an asset is not ours simply because it is named after us, linked from a repository, or referenced by our documentation.
Please confirm ownership before you submit. Reports about storage buckets whose name contains “github”, preview deployments and third-party hosting linked from a repository, Microsoft or Azure services, and vendor tooling running on a subdomain are all regularly closed for this reason. The same applies to credentials: a key committed by one of our users is not a GitHub credential. See GitHub Credentials for what we do consider in scope.
Some findings describe getting more of something than you are entitled to, rather than crossing a security boundary. Bypassing a usage limit or quota, resetting a trial, avoiding a charge, consuming another account’s allowance, or provoking our moderation and enforcement systems into acting against someone are handled as abuse rather than through the bounty program.
These are ineligible unless you can show a security impact alongside the abuse, such as access to another user’s data, an authorization bypass, or a material financial loss to GitHub. Please report abuse through support.
Reports whose impact depends on an attacker controlling what GitHub sends to another user over the network are ineligible. If the attack requires a machine-in-the-middle position, a modified API response delivered to the victim, or a certificate added to the victim’s trust store, then you are demonstrating what happens when transport security is already defeated rather than a flaw in our products.
Using an intercepting proxy or browser developer tools locally to simulate a plausible content-injection point while testing a separate security control, such as GitHub.com’s Content Security Policy, is permitted and does not make the report ineligible by itself. The report must still demonstrate that the intended control can be bypassed in a location where content injection could realistically occur.
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.
This is the most common ineligible Dependabot report we receive. A manifest, lockfile, or build script that runs your code during an update job is doing exactly what the job is for. The finding starts at the sandbox boundary. Your report needs to show something concrete on the other side of it, such as reaching an internal host, reading another customer’s data, or obtaining credentials that outlive the job. Proof that your code ran, that you can see the container filesystem, or that you have network access to the public internet is not a sandbox escape.
Dependabot acts on the repository that enabled it, using permissions that repository granted. Opening pull requests, reading the dependency graph, and writing to a branch it created are intended. Reports that someone who can already push to the repository can influence a Dependabot run are ineligible.
Findings in third party packages, or in advisories published about them, belong to those maintainers. Report them to the package owner or through the GitHub Advisory Database. Reports that Dependabot did not alert on a given package, alerted late, or scored an advisory differently to another source are ineligible.
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.
Raw gist files and user uploaded images are served from githubusercontent.com rather than github.com precisely so that active content cannot reach your GitHub session. Scripting that executes on that domain, including in an SVG, has no access to github.com cookies. See the githubusercontent.com page for what is and is not eligible there.
A gist can contain any text, including links to sites the author controls. Reports that a link in a gist leads somewhere hostile, or that a URL shortener obscures its destination, are ineligible. The same applies to the interstitial we show when leaving GitHub: it is a warning, not a security boundary.
Gist history is kept in Git, so a revision that was once public may remain reachable through the Git interface or through a fork after the gist is edited or deleted. Treat anything published in a gist as published. If you committed a secret to a gist, rotate it.
A workflow job is a single trust domain. Any step that can run code in a job can already read the job’s token, the secrets passed to that job, the workspace, the environment, and the runner’s filesystem, and can influence every later step in the same job. Writing to GITHUB_ENV or GITHUB_PATH, setting a library preload variable, or altering a cache that a later step restores are all ways of doing something the step could already do directly.
Reports that move between steps of the same job are therefore ineligible. To be eligible, show the boundary around the job failing: reaching another repository, another job’s secrets, another customer’s runner, or job-scoped credentials that remain valid beyond their documented lifetime.
The upload and download artifact actions package and unpack whatever paths the workflow points them at. The workflow author chooses those paths, and anyone who can change the workflow or run code in the job can already read the files being packaged. Filtering of hidden files is a convenience so that people do not ship .git by accident, not a control over what a workflow is permitted to include.
Reports that a workflow can be made to include a hidden file, follow a symlink in its own workspace, or write outside the extraction directory when the artifact is created and consumed within the same job are ineligible. To be eligible, show the artifact crossing a job or repository boundary, such as an artifact from an untrusted job overwriting files used by a more privileged job, one repository reaching another repository’s artifacts, or an artifact becoming readable by someone who could not already read the repository.
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:
http://169.254.169.254Access 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.
It is intentional that write access to a repository allows users to list Actions secret metadata, retrieve the public key used to encrypt secrets, and create, update, or delete secret values, as documented in the REST API reference. Users with write access are expected to be able to create and edit workflows, which requires being able to configure the secrets those workflows use.
Existing plaintext secret values cannot be read back. A report showing that a write-access user can retrieve one is not covered by this exclusion.
Content in a public repository is public, including through the API. Reports that an API endpoint returns source code, file contents, commit history, or other data belonging to a public repository are not vulnerabilities. This applies even where the same data is harder to reach through the web UI. To be eligible, a report must show the API returning data from a private resource to a user who is not authorised to see it.
Metadata such as repository names, timestamps, counts, language statistics, topic tags, and similar attributes is not treated as sensitive. Reports that the API discloses metadata, without showing access to private content or a privilege escalation, are ineligible.
Features may be turned off in the web UI, for example wikis or projects, without that being a hard security boundary. Reaching the equivalent functionality through the API is generally ineligible. See accessing certain disabled functionality for the full explanation.
There are several ways to determine that an email address is in use on GitHub, and we have accepted that risk in exchange for usability. Commit author email addresses in particular are set by the developer and are used for attribution, which is explained under impersonating a user through git email address. Reports about email addresses being visible or enumerable through the API are ineligible unless you can show a private email address being disclosed to a user who should not have it.
An attacker who can already run commands as you, read your files, or set your environment variables has everything the CLI has. Reading the token out of the config file or the keyring, setting GH_TOKEN or GH_HOST, or editing the config to change where requests go are all consequences of that access rather than separate vulnerabilities. To be eligible, a report needs to show an attacker without local access obtaining credentials or execution.
gh extension install and gh alias set run code you have chosen to install, and extensions are ordinary repositories written by other people. That the code then runs is the intended behaviour, not a sandbox escape. Reports that an installed extension or a configured alias can act with your credentials are ineligible.
The CLI sends your credentials to the host it is configured to talk to, including GitHub Enterprise Server hosts you have authenticated against. Reports that a token is sent to a configured host, or that a token works against the API it was issued for, are working as designed. A report is eligible if you can show credentials for one host being sent to a different host.
Cloning a repository means running its content through Git, and Git is designed to let repositories configure their own behaviour. See our position on repositories you do not trust before reporting. A report is eligible if the CLI does something Git itself would not, or if execution happens without the user taking any action on the repository.
Opening a repository in a codespace runs that repository’s devcontainer configuration, including its lifecycle commands. If you do not trust the repository, do not open it in a codespace. Code running there acts as you and can use the token available to that environment.
That token is scoped to the repository the codespace was created for. Reports showing a devcontainer running commands, reading the workspace, or using the codespace token against its own repository are ineligible. A report is eligible if you can show the token or the environment reaching a different repository, another user’s codespace, or data outside that scope.
A token scope controls which endpoints a token may call. It does not shrink the access the account already has. A token carrying the codespaces scope can therefore act on private repositories its owner can already reach, including creating a codespace for them, and that is the intended design rather than an escalation. Reports that a scope grants access the user already had are ineligible.
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:
docker.sock)/procThis 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.
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.
Premium request counts, quota resets, plan upgrades and downgrades, trial eligibility, and payment state are billing matters rather than security boundaries. Reports that you can obtain more Copilot usage than you paid for, reset a limit, or enrol yourself in a plan you are already able to enrol in are ineligible, and are handled as abuse through support.
A report is eligible if the billing behaviour also crosses a security boundary, for example consuming another organization’s entitlement, or reading another customer’s usage or payment data.
Related reports we also close: enrolling an account you already control into a free tier, code in your own codespace or workspace using the token available to it to do the same, changing your own telemetry preference, and reading model names, versions, or policy metadata. None of these reach another customer’s data.
Copilot proposes; you decide. When Copilot describes a change to your project, including to build files, configuration, or scripts, and you accept it or run the result, the outcome follows from your decision. Reports that untrusted content influenced a suggestion that you then approved are prompt injection, covered above.
To be eligible, show the change being applied or executed without the confirmation that step normally requires.
The MCP server exposes GitHub data and actions to an AI client using your own credentials, so it can reach whatever you can reach. Tool annotations and descriptions are advisory metadata for the client, not an authorization control we enforce.
Reports that repository content, issues, or search results influence what a model does, or that a client chose to call a tool marked read-only, are prompt injection and are covered above. To be eligible, show the server itself returning data your token should not reach, or performing an action your token should not be able to perform.
Any Copilot chat conversations that are off topic and not programming-related are not eligible.
When the coding agent is assigned an issue, it reads that repository and works in an environment scoped to it. Reports that the agent read the repository’s code, issues, or workflow files, or that it ran the repository’s own setup steps, describe the feature working. An eligible report shows the agent reaching a repository, secret, or network resource outside the one it was assigned to.
Anyone with the permission to assign issues in a repository can assign the agent, and the agent then works with that repository’s access. That is the intended model. Reports that a collaborator can direct the agent, or that an issue title or body influences what the agent does within its own repository, are ineligible. Content the agent reads is untrusted input, and steering it is prompt injection, covered above.
The agent opens pull requests for a human to review, and its branches are subject to the same branch protection and required review settings as any other contributor. Reports that the agent proposed insecure or incorrect code are ineligible for the same reasons as suggested code above. An eligible report shows the agent’s changes reaching a protected branch without the review that branch requires.
GitHub Secret Scanning automatically detects credentials accidentally committed to repositories for a number of service providers. Credentials for GitHub, Inc. resources that have already been found through 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.
We need to know that a credential is live and what it reaches. Do not test beyond the minimum needed to confirm validity, but do tell us what you did confirm: which service it belongs to, what a successful call returned, and roughly what access it implies. A string that looks like a key, or a hit from a scanner with no validation behind it, is ineligible. Never use a credential to read data, change state, or move further into our systems.
Public API keys, client identifiers for public OAuth apps, analytics and telemetry tokens, keys scoped to a single public dataset, and credentials for services with no GitHub data behind them are ineligible even when they are clearly ours. The same applies to keys that appear in a commit but were rotated before you found them.
Actions secrets are available to the workflows in the repository that owns them, and are redacted from logs on a best effort basis. Reports that a workflow you can modify can read the secrets available to it, or that an unusual encoding defeats log redaction, are ineligible. Redaction is a convenience, not a boundary: treat any secret a workflow can read as readable by anyone who can change that workflow.
Adding or cloning a repository means letting Git process repository content that its author controls. It does not copy the attacker’s .git/hooks or .git/config into the new working copy. Desktop is a Git client, so reports where the whole chain is “the user cloned my repository and then Git processed the repository content as designed” are ineligible. A report may be eligible if Desktop mishandles that content, runs something Git would not have, or crosses a security boundary before the user has taken any action on the repository.
Chains that require the user to open a specific file, change a setting, approve a prompt they had a reason to refuse, or follow instructions from the attacker are social engineering. If your report includes a step like this, describe it plainly and explain why the user would realistically take it.
An attacker who can already write to your disk or run as your user can read Desktop’s stored credentials, edit its configuration, and replace its files. Reports that describe reading a token from local storage, or modifying local state to change behaviour, are ineligible without showing how a remote attacker reaches that state.
Desktop is a public client, so its client ID is embedded in the application and is not a secret. Reports that it can be extracted are ineligible.
A GitHub Classroom assignment invitation link can be accepted by anyone who has the link, and accepting it associates that account with the assignment. This is intentional, because teachers share these links through their own channels and we cannot know which accounts are meant to receive them. Treat an invitation link as something to share carefully. Reports that an unintended account can accept a shared link are ineligible.
GitHub Classroom acts on an organization the teacher owns, so it can create repositories, manage teams, and add or remove members within it. Reports that a teacher or organization owner can perform these actions, or that removing a student from a classroom does not immediately revoke every prior access, are working as designed.
Repositories created by Classroom follow the visibility the teacher selected. Assignment content, submitted code, and roster identifiers in a public repository are public. Reports that this content is readable are ineligible unless you can show a private repository being exposed.
Enterprise owners, organization owners, and repository administrators have broad access by design, including to private repositories, member data, audit logs, and billing. Custom repository roles grant whatever permissions the organization assigned to them. Reports that an account with one of these roles can see or do something within its own scope are working as designed. Before reporting, check the permission tables in our documentation and say which specific permission the account should not have had.
A user who can push to a branch can change the workflows that run from it, and workflows run with whatever permissions the repository and organization settings allow. Reports that a workflow can read secrets available to it, or that a maintainer can add a workflow step, are ineligible. Show a workflow reaching secrets or resources belonging to a repository or organization it should not.
IP allow lists restrict where requests may originate. They are not intended to hide the existence of an organization, block unauthenticated public content, or protect against a member who is inside the allowed range. Reports that public data is still public, or that an allowed address still works, are ineligible.
Sending an invitation to an email address, a member consuming a seat, and usage counting against a billing plan are all intended behaviour. Reports about billing quantities without a demonstrated financial impact to GitHub or another customer are ineligible. See our position on Copilot and consumption billing.
Enterprise owners can choose whether an unauthenticated request for an enterprise resource returns a 404 or redirects to single sign on. Where an administrator has enabled the redirect, it will reveal that the resource exists. That is a consequence of the setting they chose, so reports that the redirect distinguishes a real resource from a missing one are ineligible unless you can reach the private content itself.
A policy that restricts repository visibility governs the actions it names, which is creating a repository and changing an existing repository’s visibility. It is not a guarantee that no public repository can ever appear in the organization. Forking a public repository, transferring one in, and other routes that bring an existing repository along with its current visibility are governed by their own separate settings.
Reports that a visibility policy did not block a fork or a transfer are ineligible. Read the policy’s own description first, and to be eligible show a member changing the visibility of a repository in a way the policy says it prevents.
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.
Some public DNS records resolve to RFC 1918 or otherwise internal addresses. On its own this tells an attacker nothing they can act on, because they still cannot route to those hosts. These reports are ineligible unless you pair them with a working path to reach the address, such as a server side request forgery that we can reproduce.
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.
A Pages build runs the repository’s own configuration and theme, so a user who can push to the repository can influence what the build does. That is the point of the feature. An eligible report shows a build reaching outside its own boundary: another repository’s source, another customer’s build, credentials belonging to GitHub, or the internal network. Show what you reached, not just that your code ran.
Custom domain verification proves that a domain owner intends to point at a particular account. It does not prevent anyone from setting a CNAME file in their own repository, and an unverified domain that nobody has claimed is not a vulnerability by itself.
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 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. 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, so reports that stop at “GitHub fetched my URL” are ineligible. The proxy is intended to run where it cannot reach internal addresses, and that restriction is a control we do defend: if you can get it to reach an internal host or port, or to distinguish internal hosts by their responses or timing, that is eligible and we want the report.
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 every bug is a vulnerability. A form that accepts a malformed value, a setting that displays confusingly, a field that could validate more strictly, or an interface that behaves unexpectedly are product bugs, and support is the right route for them.
These become eligible when you can name what an attacker gains. If the change only happens after the account owner opens the page and saves it themselves, or the malformed value is only ever shown back to you, there is no security boundary being crossed.
Issue and pull request creation accepts query parameters that prefill the title, body, labels, assignees and template selection. A link can therefore open a form with content the author of the link chose. Nothing is created until the person clicking it reviews the form and submits it themselves, and the resulting issue is attributed to them.
Reports that a crafted link prefills a form, selects a different template, or skips a template chooser are ineligible. To be eligible, show the parameters creating or modifying something without the user submitting it, or granting access the user does not already have on that repository.
A deploy key with write access is repository owner automation. It acts in the owner’s context, so where a ruleset already lists the repository owner or an owner-owned app as a bypass actor, a write deploy key inherits that bypass. This is the configuration working as set, not a way around it.
Check the ruleset’s bypass list before reporting. To be eligible, show a ruleset being bypassed by an actor that is not on that list, or a key acting on a repository it was never added to.
Display names, usernames, biographies, and avatars are chosen by the account holder and are not a statement that we endorse anyone. Accounts that resemble GitHub staff, our triage team, or an official programme are a known abuse problem rather than a technical vulnerability, and reports whose impact depends on someone believing a profile is official are ineligible. Please report accounts impersonating GitHub through support.
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.
A dangling DNS record is only eligible once you can show that you are able to claim the target and serve content from it. A CNAME pointing at a provider, a NoSuchBucket page, or a default landing page is not enough on its own. Include evidence that you registered the resource, and do not host anything beyond a harmless proof file.
Some subdomains point at vendor services such as identity providers and support tooling. Findings in the vendor’s own product should go to that vendor. We are interested in cases where the integration itself is broken, for example a misconfiguration that lets you reach GitHub data you should not have.
Directory listings, static assets, health check endpoints, build metadata, and framework version banners on these hosts are ineligible on their own. Explain what an attacker gains from the disclosure.
We serve user-uploaded content from *.githubusercontent.com specifically to isolate it from github.com and its cookies. Cross-site scripting, open redirects, and similar behaviour in an SVG or other uploaded file are contained by that separation. Demonstrating only that user-controlled content behaves in a user-controlled way is a known low risk and is ineligible.
We also apply a Content Security Policy as an intended security control. A report that reproducibly bypasses that policy may qualify as defense in depth even when the independent domain separation prevents user impact. A report that reaches github.com, its cookies, or its session state is eligible based on that demonstrated impact rather than as defense in depth.
When you use the Raw button on a private file we generate a URL containing a cryptographically signed, time-limited token. That token authenticates access to that file for that user, and it works for anyone holding the URL until it expires. This is by design, so treat the URL as you would the file itself. Reports that a raw URL grants access without a session are ineligible unless you can show a token being forged, extended, or reused after expiry.
Images and files attached to a private issue or pull request are served from a URL containing an identifier that is intended to be unguessable to someone without access to the repository. Treat the URL as you would the file itself. Reports that an attachment URL remains reachable to someone who was given it are ineligible. Reports that the identifier can actually be predicted, enumerated, or recovered from another endpoint are eligible, and we have rewarded them, so it is worth testing rather than assuming.
Credentials committed by our users are not GitHub credentials and are not in scope. See GitHub Credentials for what we do consider in scope, and please report user-owned secrets to the repository owner instead.
npm reads configuration from the directory you run it in, including the project .npmrc, and that file can change where npm looks for further configuration. If you cloned an attacker’s repository and ran npm inside it, the project files are attacker-controlled content you chose to trust, in the same way the lifecycle scripts below are.
Reports that a project .npmrc overrides your user settings, redirects a registry, or suppresses a warning are ineligible. A report is eligible if npm does something that does not depend on you having chosen to work inside that project.
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.
Reports described as account takeover must work against a user who is behaving normally. Chains that need the victim to enter their password into a page you control, click a link you sent them, accept an invitation, or hand over a token or one-time code are social engineering rather than a flaw in npm. If the victim has to help, say so plainly in the report and explain why the step is realistic.
Package names, versions, publish timestamps, dependency lists, maintainer usernames, and the contents of public packages are all intentionally public. The same applies to publisher email addresses where the publisher has chosen to make them visible. Reports that this data can be collected or enumerated are ineligible without a demonstrated impact beyond its availability.
Invitations, membership removal, and ownership transfer behave as designed, including that an invitation sent to an email address can be accepted by whoever controls that address. Reports that a member can be added or removed by someone with the permission to do so are not vulnerabilities.
Lost accounts, accounts registered against an email address you own, and disputes over a package name are handled by support rather than the bounty program.
Being able to revoke a token whose unguessable identifier you already hold is a known low risk. The result is that the owner has to create a new token, which is inconvenient rather than a compromise. These reports are ineligible unless you can show the identifiers are predictable or enumerable, or that you can use the token rather than only destroy it.