Reward Nomination Process

An important part of Chromium's VRP is the process of nominating confirmed externally-reported vulnerabilities for reward.

Periodically, someone from the Chromium Reward Panel will do a sweep of the bug tracker for issues flagged with the label reward-topanel. You can hit this link for a simple query which returns all such issues. An e-mail is then sent to, titled "Nominating #, #, # for reward" where # represents a bug id. The body of the message consists of a link to the panel voting doc, with the new reward proposals at the top. A consensus will determine the reward amount. In the extremely rare cases where a consensus cannot be reached, a majority vote will be used.


Over the history of the reward program, we have strived to hit a balance of a few cultural items.
  • Humility and generosity. Generally, we're looking for reasons to reward or reward more, as opposed to reasons to not reward or apply subtractive penalties to a possible reward. This cultural item has led to a lot of happy participants and "repeat custom".
  • Minimize pain to Chrome Security Team. We try to set up incentives so that bug reporters provide high quality reports that enable us to get fixes to users with minimal fuss. An example of causing pain is when a reporter dumps a 100kb fuzz file with no attempt to minimize / isolate the conditions required for the fault.
  • Consistency. Whilst there will always be a little bit of subjectivity to the reward process, it's important to consistently pay the same reward value for bugs of similar quality and impact. This had let to an openly published track record of reward consistency, leading to greater trust in our program.
  • Focus on protecting the user. At the end of the day, the main thing that matters is: did the report help or enable us in protecting users? For example, we've paid in cases where we knew about the bug but were not aware of its security impact. This new awareness led us to merge it sooner, corresponding to users protected sooner.

There is often interplay between the above items. For example, if a bug reporter seems to have genuinely tried to reduce a complicated test case, but it's just a really tricky case, our generosity will enable us to overlook this. Conversely, if a bug reporter in unresponsive or uncollaborative for requests to clarify a tricky report, there has to be a limit to our generosity.

Typical base rewards

  • $500 for any Medium severity out-of-bounds memory issue, where there's reasonable suspicion of an info leak of the out-of-bounds access.
  • $500 for any High severity memory safety issue where there are concerns over the quality of report (e.g. huge complicated repro, no attempt to simplify).
  • $1000 for any High severity memory safety issue where the report is of good quality (simple, clear repro).
  • $1000 for any High severity cross-origin issue.
  • $3133.7 for any Critical severity memory safety issue where the report is of good quality.

Reward modifiers

  • +$500 if the reporter lands a patch to fix a Medium+ severity issue through the standard Chromium review process.
  • +$1000 if the reporter lands a patch as per above, but the fix ends up being non-trivial.
  • +$1000 - $4000 if the reporter demonstrates probable exploitability. See below.
  • +$1000 if the bug affects a component which has significantly wider applicability beyond Chromium.

Demonstrating probable exploitability

As can be seen, the largest reward modifier by far is for demonstrating probable exploitability. This absolutely does not require a full exploit, but does require notes covering as many of the following as feasible:

  1. Adhering to the general guidelines in our Reporting Security Bugs document. A minimal, easy-to-use repro remains essential.
  2. Where possible, a clear stack trace indicating any memory error. For example, a symbolized AddressSanitizer (ASAN) output log.
  3. For use-after-free bugs, a demonstration of the capability of exercising adequate control between the free and the use. e.g. allocating an attacker-chosen object into the freed slot.
  4. For use-after-free bugs, demonstration of a consequence of the "use" -- such as a vtable load, or a write of a controlled value to a significant
  5. For out-of-bounds read bugs, a demonstration of egress of the out-of-bounds content to JavaScript, or JavaScript influence of the effect of the out-of-bounds read.
  6. For buffer overflow bugs, a demonstration of a corruption of a significant object with attacker-controlled values.
  7. Where possible, notes on where things are going wrong in the code, both the vulnerability itself as well as where the subsequent effects of the corruption are manifesting.

The rewards panel reserves the right to reward outside and beyond the values documented above for work of extremely excellence or significance. For example, $7331, $10,000 and even $30,000+ rewards have been issued for awesome work -- typically fully working exploit chains where the exploit chain has taught us something new. The latest reward structure de-emphasizes exploits in favour of paying relatively more for good bugs. This is to encourage researchers to send bugs to us sooner, so that we can protect users sooner.

Note that the reward values discussed here are separate to Google's Pwnium competitions, which are totally separate.

(New) Canonical examples

[This section will be updated with canonical examples under the new larger reward amounts, once we receive some $5,000-class bugs]

(Old) Canonical examples


A great report with a small, clear repro (small enough to actually be pasted in the bug). Report includes clear statement of affected versions (just dev channel), and an ASAN stack trace explaining the root cause (use-after-free). A memory corruption manifesting within the sandbox, so High severity.


A medium severity out-of-bounds read ($500 base) but the great quality report included an exploit that starts to read arbitrary pointers out of memory, so bonus exploitability modifier (+$3000)


A high-severity universal XSS (UXSS) bug ($1000 base). However, the repro for a UXSS is typically synonymous with a full exploit (+$3000 bonus). The reporter provided a relatively simple fix which passed the review process (+$500)


A high-severity use-after-free issue in a sandboxed process ($1000 base). Comment 25 in the bug adds a repro which illustrates a crash on the pointer 0x4141414141414141 (+$1000 probably exploitability bonus).


A high-severity issue, but the provided repro was not tidy, minimal or reliable.