Google’s Open Source Software Vulnerability Reward Program recognizes the
contributions of security researchers who invest their time and effort in
helping us secure open source software released by Google (Google OSS). Through
this program, we provide monetary rewards and public recognition to researchers
who disclose vulnerabilities in Google OSS to us.

## Repositories in scope

The program covers all the latest versions of open source software stored in the
public repositories of Google-owned GitHub organizations and selected
repositories hosted on other platforms.

The program also covers repository configuration settings (e.g. GitHub actions,
access control rules, GitHub application configurations).

### Third-party dependencies

A critical element of the security of a software package is the security of its
dependencies, so [vulnerabilities in 3rd-party dependencies](http://OSV.dev) are
in scope for this program.

That said, please send your bug reports directly to the owner of the vulnerable
package first and **ensure that the issue is addressed upstream before letting
us know of the issue details**. Just like we would like to learn about
vulnerabilities in our code first, we feel 3rd-party code authors should have
the same advantage.

Submissions detailing vulnerabilities through 3rd-party dependencies should:

*   Demonstrate that the vulnerability manifests itself in our projects (i.e.
    you must show that the 3rd-party vulnerability can be triggered or exploited
    in Google OSS).
*   Be shared no earlier than 30 days after the issue was fixed upstream (e.g. a
    patched software package was released).

Vulnerabilities in 3rd-party *services* or *platforms* used to maintain and
build Google OSS (e.g. source code management systems, CI/CD systems, package
managers) are *out of scope for this program*. We cannot authorize you to
conduct security research of assets that belong to other users and companies on
their behalf. That said, we welcome submissions describing vulnerabilities in
our configuration or integration of those 3rd-party services.

## Qualifying Vulnerabilities

### Supply chain compromises

First and foremost, we welcome submissions pointing out vulnerabilities
affecting source or build integrity that could result in a **supply chain
compromise**. Supply chain vulnerabilities include the ability to compromise
Google OSS source code, and build artifacts or packages distributed via package
managers to users. For example:

*   Ability to modify or submit code on main branches of repositories
*   Vulnerabilities in the configuration of build and release infrastructure
    that lead to the compromise of artifacts that are distributed to users,
    e.g.:
    *   Vulnerabilities in Google OSS GitHub Actions configuration
    *   Insecure configuration of a project's GCP build environment setup
    *   Disclosure of package manager credentials for publishing build artifacts
*   Compromise of cryptographic signing keys for published artifacts

Important: You must be able to demonstrate that the vulnerability is
exploitable, **bypassing the requirement that external contributors must first
have PRs approved**. This can be achieved either by exploiting a vulnerability
in an organization or repository that does not enforce this requirement, through
a time-of-check-time-of-use (TOCTOU) vulnerability, or by other means. If your
vulnerability will only trigger after approval by a maintainer, the
vulnerability will be considered for "Credit" as it will be treated only as an
insider risk.

### Product vulnerabilities

<font color="#4285F4"><b>As of October 1, 2026, we are no longer accepting
product vulnerabilities submitted to the OSS VRP. For some Google Cloud repos
impacting Google Cloud products we may still accept reports covering product
vulnerabilities through the Cloud VRP. We will continue to reformat and work on
this aspect of the OSS VRP and commit to giving an update in Q1 2027. In the
meantime, we encourage you to find impact across our other VRP programs and
submit there instead, or pursue the Patch Rewards Program. This change does not
affect product vulnerabilities submitted before October 1, 2026.</b></font>

Any design or implementation issue in Google OSS that causes a **product
[vulnerability](/learn/improving-your-reports/getting-started/6450430198153216/what-is-a-security-vulnerability)**
substantially affecting the confidentiality or integrity of user data in
software builds using Google OSS is also in scope for the program. Some
examples:

Note: For vulnerabilities in Google's open source projects that are closely tied
to Google Cloud or AI products, we encourage you to report them to the
[Google Cloud Vulnerability Reward Program](/about/rules/google-friends/4849867320328192/cloud-vulnerability-reward-program-rules)
or the
[AI VRP](/about/rules/google-friends/5222232590712832/ai-vulnerability-reward-program-rules)
to help us route your report to the right engineers.

*   Memory corruption issues in file format parsers or network protocol
    implementations
*   Failures in the sanitizer functions (e.g. HTML sanitizers)
*   Path traversal issues
*   Bad defaults or insecure code examples in project documentation

#### Acceptance criteria for product vulnerability type reports

The criteria for accepting product vulnerability type reports in the OSS VRP
program depend on the project’s tier (OT0-OT3) and the subcategory of
vulnerability, specifically:

*   All memory corruption vulnerabilities for **OT0** and **OT1** tier
    repositories require either exact
    [OSS-Fuzz reproduction steps](https://google.github.io/oss-fuzz/advanced-topics/reproducing/)
    (using an existing fuzz target, and including exact steps to
    [build the image](https://google.github.io/oss-fuzz/advanced-topics/reproducing/#building-using-docker))
    or an already merged patch in the target repository.
*   Non-memory corruption vulnerabilities in **OT0** and **OT1** tier
    repositories do not require a merged patch for submission.
*   For all projects in the **OT2** (Standard) and **OT3** (Low-Priority) tiers,
    all types of "Product Vulnerabilities" are not eligible for monetary reward.

We aim to have our important projects (**OT0** and **OT1**) integrated with
OSS-Fuzz when relevant, as this provides a more robust and scalable defense than
triaging individual memory corruption issues; we prioritize rewards for
researchers who contribute to this robust security model. For this reason, if a
memory corruption vulnerability is found in an **OT0** or **OT1** project that
lacks an existing or complete OSS-Fuzz integration, we encourage building the
integration before sending the report to the VRP program.

Please note that **rewards are granted based on security impact alone**. For
tiers where a merged patch is required for submission, the existence of a patch
is a prerequisite but **not a guarantee of a reward**; the panel determines the
overall security impact of the underlying issue at its own discretion.

### Other security issues

We would also like to know about issues that affect the security of the target
projects, but don't map to the above categories as they are not technical
security vulnerabilities. For example:

*   Sensitive credentials that give write access which have been stored in
    personal projects (e.g. dotfiles)
*   Credential leaks in publicly stored backups
*   Weak passwords for 3rd-party CI systems for which we don't control the
    password policy
*   Insider risk, i.e. vulnerabilities that are only exploitable by maintainers
    or those with elevated permissions. There must be a realistic attack
    scenario for the attacks originating from non-maintainers. As a reminder,
    social engineering attacks are explicitly out of scope for rewards.

There are a couple of classes of vulnerabilities that generally do not qualify
for a reward:

*   Security vulnerabilities and weaknesses with a root cause in downstream
    software integration with Google OSS (e.g. insecure configuration of Google
    OSS libraries, or third-party code calling Google OSS functions documented
    to accept sanitized inputs, with non-sanitized inputs).
*   Typosquatting / dependency confusion, unless it can be demonstrated how this
    leads to a compromise of Google OSS build artifacts distributed to users.
*   Insecure installation / software usage instructions that compromise the
    security of the developers working on the product
*   For all projects in the **OT2** (Standard) and **OT3** (Low-Priority) tiers,
    all types of "other security issues" are not eligible for monetary reward.
*   Issues with negligible security impact, as described in the
    [Bug Hunter University](/learn/invalid-reports/5374985771941888/about-this-section).

Out of concern for the availability of our services to all users, please do not
attempt to carry out DoS attacks, leverage black hat SEO techniques, spam
people, or perform other similarly questionable actions. Whenever possible,
please try to test the vulnerabilities locally without impacting other users. We
also discourage the use of any vulnerability testing tools that automatically
generate significant volumes of traffic.

## Project tiers

Project tiers indicate the sensitivity and criticality connected with projects,
and have implications for the reward amounts the VRP grants to researchers. The
full list of **OT0** and **OT1** repositories can be found at
**[https://github.com/google/bughunters](https://github.com/google/bughunters/blob/main/oss-repository-tier/external_repositories.txtpb)**.

### Flagship OSS projects (OT0)

This tier contains selected Google open source projects that we consider
particularly sensitive. Rewards for vulnerabilities found in projects in this
tier are significantly higher than for projects in other tiers. The full and
up-to-date list of **OT0** repositories can be found at
**[https://github.com/google/bughunters](https://github.com/google/bughunters/blob/main/oss-repository-tier/external_repositories.txtpb)**.

### Important OSS projects (OT1)

The Important (**OT1**) tier includes repositories with significant community
impact or high security criticality. For a full and up-to-date list of **OT1**
repositories, please refer to
**[https://github.com/google/bughunters](https://github.com/google/bughunters/blob/main/oss-repository-tier/external_repositories.txtpb)**.
Only the projects mentioned explicitly as **OT1** in this list fall under the
**OT1** category.

### Standard OSS projects (OT2)

This tier contains all software repositories that are not explicitly mentioned
in the criteria of other tiers. Typically, they fulfill all of the below
requirements:

*   Repository is active and open to receive commits (i.e. not labeled as
    archived, deprecated, or in maintenance mode).
*   Repository stores code of a software library, framework, or end-user
    product.
*   Build artifacts from the repository are published in one of the popular
    package manager registries (e.g. npm, PyPI).
*   Released packages are marked as stable, release candidate, or late beta.

Note that there is no published list of **OT2** repositories and the tier
decision when rewarding a report is at the discretion of the reward panel.

### Low-priority OSS projects (OT3)

This tier contains small, experimental, sample, and other low-priority projects.
Projects in this tier typically have some combination of the following
properties:

*   Non-existent or small community impact
*   No active development
*   Marked as "experimental", "demo", "sample", etc.
*   Unofficial project under a Google org
*   No executable code in the project (e.g. projects serving documentation
    websites)
*   Projects accompanying research projects conducted by Googlers
*   Repository belongs to "google-research", "googleinterns", "googlearchived",
    or similar GitHub orgs
*   No CI/CD setup on the repository

We currently do not financially reward submissions describing issues in projects
from this tier.

## Reward amounts

The following table outlines typical rewards for the most common classes of
bugs, depending on the affected project tier.

<table border="2" bordercolor="#ffffff">
  <tr>
   <th>Category
   </th>
   <th>OT0 (Flagship)
   </th>
   <th>OT1 (Important)
   </th>
   <th>OT2 (Standard)
   </th>
   <th>OT3 (Low-priority)
   </th>
  </tr>
  <tr>
   <td>Supply chain compromises
   </td>
   <td>
    $3,133.7 - $31,337
   </td>
   <td>$1,337 - $13,337
   </td>
   <td>$500 - $3,133.7
   </td>
   <td>-
   </td>
  </tr>
  <tr>
   <td>Product vulnerabilities
   </td>
   <td>
    -
   </td>
   <td>-
   </td>
   <td>-
   </td>
   <td>-
   </td>
  </tr>
  <tr>
   <td>Other security issues
   </td>
   <td>
    $1,000
   </td>
   <td>$500
   </td>
   <td>-
   </td>
   <td>-
   </td>
  </tr>
</table>

<p></p>

The final amount is always chosen at the discretion of the reward panel. In
particular, we may decide to pay higher rewards for unusually clever, severe, or
wide-reaching vulnerabilities; decide to pay lower rewards for vulnerabilities
that hinge on the existence of other, not-yet-discovered or hypothetical bugs to
become exploitable, require unusual user interaction or other rarely-met
prerequisites; decide that a single report actually constitutes multiple bugs;
or that multiple reports are so closely related that they only warrant a single
reward.

For every reported vulnerability, the security impact is evaluated by looking at
the most dangerous attack scenario that the panel can come up with. If we
discover higher-impact attack vectors that the original reporter hadn't
considered in the submitted report, we bump up the score accordingly. When
receiving multiple reports, we typically only reward once per root cause and
group similar vulnerabilities together. We might also give small bonus increases
of approximately $1,000 USD for particularly clever or interesting
vulnerabilities, and for particularly well-written reports.

We understand that some of you are not interested in money. We offer the option
to donate your reward to an established charity. Any rewards that remain
unclaimed after 12 months will be donated to a charity of our choosing.

We also encourage you to check out our
[Patch Rewards program](/about/rules/4928084514701312/patch-rewards-program-rules),
which offers rewards for making security improvements to Google’s open source
projects.

## Reporting bugs

All bugs should be reported using the [vulnerability form](/report/vrp) (in the
**Bug Location** step, select *OSS VRP* and specify the repository URL).

We ask you to submit high-quality reports, including as many details as
possible, a buildable proof of concept against a recent build, a crash dump if
available, and instructions on reproducing the issue. Please also include
information about the affected software version, a description of the issue’s
impact, and an attack scenario, as that helps us assess the vulnerability
quickly and effectively.

For product vulnerabilities, please also refer to the
[Acceptance criteria for product vulnerability type reports](https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules#acceptance-criteria-for-product-vulnerability-type-reports)
section for more requirements.

For tips on improving your reports, also refer to the
[Bug Hunter University](/learn/improving-your-reports/6005260747014144).

## Code of conduct

To ensure a healthy and productive relationship between bug hunters and the
Google teams interacting with them, we have defined a
[Code of Conduct](/about/rules/other/6009584292331520/code-of-conduct-for-our-vulnerability-reward-programs)
laying out the expected behaviors from both sides.

Thank you in advance for familiarizing yourself with this code and adhering to
its provisions!

## Legal points

We are unable to receive reports and/or issue rewards to individuals or entities
that are on sanctions lists, or who are in territories subject to sanctions
(e.g., Cuba, Iran, North Korea, Syria, Crimea, and the so-called Donetsk
People's Republic and Luhansk People's Republic). Additionally, due to
administrative difficulties, we no longer issue rewards to individuals or
entities located in Russia or Belarus.

Unless otherwise authorized in advance, in order to qualify for a reward,
reports submitted to the VRP at any period of time may not utilize Alphabet
proprietary, confidential, or need-to-know information. We will evaluate every
submission on a case-by-case basis.

Participation in the program is restricted to individuals aged 18 and older. To
enable us to formally evaluate (and, if applicable, reward) your report, if
you're under 18 years of age, please have a parent, guardian, or other trusted
adult submit the report on your behalf.

You are responsible for any tax implications depending on your country of
residency and citizenship. There may be additional restrictions on your ability
to enter the program depending upon your local law.

If Google Payments is your selected payment option and you're not a US resident
for income tax purposes, you confirm that any services you provide to Google
won't be performed in the US. If you ever plan to provide services in the US,
please let us know in writing at least 90 days beforehand by emailing
STCnotices@google.com.

This is not a competition, but rather an experimental and discretionary rewards
program. You should understand that we can cancel the program at any time and
the decision as to whether or not to pay a reward has to be entirely at our
discretion.

Your testing must not violate any law, or disrupt or compromise any data that is
not your own.

To avoid potential conflicts of interest, we will not grant rewards to people
employed by Google or Google Partner companies who develop software covered by
this program.