Chrome Vulnerability Reward Program Rules
The Chrome Vulnerability Reward Program was launched in January 2010 to help reward the contributions of security researchers who invest their time and effort in helping us to make Chrome and Chrome OS more secure. Through this program we provide monetary awards and public recognition for vulnerabilities responsibly disclosed to the Chrome project.
Scope of program
Any security bug in Chrome or Chrome OS may be considered. It’s that simple!*
* well, it's almost that simple. Two key points:
- We are interested in bugs that make it to our Stable, Beta and Dev channels. We discourage vulnerability hunting on canary or trunk builds, because they don't undergo release testing and can exhibit short-lived regressions that are typically identified and fixed very quickly.
- We'd also love to learn about bugs in third-party components that we ship or use (e.g. PDFium, Adobe Flash, Linux kernel). Bugs may be eligible even if they are part of the base operating system and can manifest through Chrome.
We will typically focus on critical, high and medium impact bugs, but any clever vulnerability at any severity might get a reward.
There are three rules to keep in mind:
- 1. Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.
- 2. Bugs disclosed publicly or to a third-party for purposes other than fixing the bug will typically not qualify for a reward. We encourage responsible disclosure, and believe disclosure is a two-way street; it's our duty to fix serious bugs within a reasonable time frame.
- 3. We take into account if the report caused us to make a security-beneficial change, i.e. we would likely not reward if we would have fixed the issue without the report.
Investigating and reporting bugs
All bugs should be reported via this form, which will apply the correct labels and view restrictions. Note that your submission is over HTTPS and does not require additional encryption. Bugs that are found in Google's server-side services should be reported under the Google Vulnerability Rewards Program instead.
When investigating a vulnerability, please, only ever target your own computers. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users or to Google.
Note that we are only able to respond to technical vulnerability reports. Chromium embedders and companies with whom Google has a pre-existing business relationship may not be eligible for rewards. Non-security bugs and queries about problems with your account should be instead directed to Google Help Centers.
Reports are made public 14 weeks after being marked as fixed, other than in exceptional cases. This is in keeping Chromium's open source philosophy, and provides a valuable resource for conducting vulnerability research. Note that attachments are considered part of the report.
Rewards for qualifying security bugs typically range from $500 to $150,000.
We have a standing $150,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page).
The following table outlines the usual rewards chosen for the most common classes of bugs:
High-quality report with
|Sandbox escape / Memory corruption in a non-sandboxed process||$30,000||$20,000||Up to $15,000|
|Universal Cross Site Scripting (includes Site Isolation bypass)||$20,000||$15,000||Up to $10,000|
|Renderer RCE / memory corruption in a sandboxed process||$10,000||$7,500||Up to $5,000|
|Security UI Spoofing||$7,500||N/A ||Up to $3,000|
|User information disclosure||$5,000 - $20,000||N/A ||Up to $2,000|
|Web Platform Privilege Escalation||$5,000||$3,000||Up to $1,000|
|Exploitation Mitigation Bypass||$5,000||$3,000||Up to $1,000|
|Chrome OS||See below|
|Chrome Fuzzer Bonus||$1,000|
|Chrome Patch Bonus||$500 - $2,000|
 For these classes of bugs, high quality reports are expected to demonstrate the UI
spoof or show how user information could be disclosed, which we treat as a functional
High-quality reports with a functional exploit:
- A high-quality report (as noted below) plus:
- Include a reliable exploit that demonstrates that the bug reported can be easily, actively and reliably used against our users.
High-quality reports typically have several of these characteristics:
- Minimized test case.
- Demonstrate that the exploitation is very likely.
- Analysis to help determine the root cause.
- Report should be brief and well written with only necessary detail and commentary.
- Be responsive to questions from the engineers working to fix the bug.
- Suggested patch.
Baseline reports should at least have:
- A minimized test case or output from a fuzzer that highlights a security bug is present without establishing that the issue is exploitable.
- The versions of Chrome affected by the bug.
Reports should avoid:
- Only a crash dump.
- Stack trace without symbols.
- Without a Proof of Concept (PoC) or poor quality PoC (e.g. a large fuzz file dump with no attempt at reduction) that is later verified to be a legitimate issue.
The amounts listed are for good quality reports that don't require complex or unlikely user interaction. Less convincing or more constrained bug submissions will likely qualify for reduced reward amounts, as chosen at the discretion of the reward panel.
Rewards apply to Chrome on Win 7+, macOS10 v10.10+, Linux, Android 4.4+, iOS 7+ and to current versions of Chrome OS.
The decision whether to grant a reward and the amount of the reward is always determined at the sole discretion of the reward panel. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.
We understand that some of you are not interested in money. We offer the option to donate your reward to a charity registered with our giving partner. If you do so, we will double your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Additional Chrome Rewards
On top of these rewards, we offer from $500 or $2,000 if a well-written patch is provided with the report.The amount for this reward is determined by the panel based on the quality and the effort required to write a good patch for the bug. Significant patches can also be submitted under our Patch Reward Program.
V8 exploit bonus
Reports affecting V8 which clearly demonstrate exploitability may qualify for increased rewards, as specified in the table below. V8 bugs in other categories may still qualify, at the panel's discretion.
High-quality report with
|Renderer RCE / memory corruption in a sandboxed process||Up to $20,000||Up to $15,000||N/A |
|Exploitation Mitigation Bypass||Up to $10,000||Up to $6,000||N/A |
 Baseline reports are unable to meet the requirements to qualify for this special
Reports for V8 bugs at the "high-quality report with functional exploit" level are likely to qualify without additional effort from the reporter. V8 bugs at the "high-quality" level may qualify if they include evidence of exploitability as part of their analysis.
The following are some examples of how a report could demonstrate that exploitation is possible, but any analysis or proof of concept will be considered by the panel:
- Executing shellcode from the context of chrome or d8
- Creating an exploit primitive that allows arbitrary reads from or writes to specific addresses or attacker-controlled offsets
- Demonstrating instruction pointer control
- Demonstrating an ASLR bypass by computing the memory address of an object in a way that's exposed to script
- Providing analysis of how a bug could lead to type confusion with a JSObject
We have a standing $150,000 reward for participants that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e., guest to guest persistence with interim reboot delivered via a web page).
Chrome OS reports should be targeted at official Chrome OS hardware running in verified mode. Reports that break individual layers without including a vector to trigger the bug via a web page or a malicious app may be evaluated in developer mode to create the appropriate starting condition.
In addition to the Chrome bug classes recognized by the program, we are interested in reports that demonstrate vulnerabilities in Chrome OS' hardware, firmware and OS components.
Additional components are in scope for sandbox escapes reports on Chrome OS. These include:
- Escaping the Android container to compromise Chrome OS browser or platform.
- Escaping Chrome OS platform service sandboxes to root privileges.
- Escaping the Linux on Chromebooks environment (aka Crostini) to compromise Chrome OS platform components.
- Obtaining code execution in kernel context.
- Escalating a compromise across user boundaries.
We're also interested in reports that demonstrate vulnerabilities in firmware, in particular main processor firmware, embedded controller firmware, fingerprint firmware, and H1 firmware,which impact critical security functionality. Reports that target peripheral firmware such as WiFi and Bluetooth modules are rewarded according to their impact on OS security.
Chrome OS Verified Boot is designed to prevent compromises to persist across reboot. Reports of bugs that defeat verified boot and allow the attacker to retain control across reboot are considered for special rewards.
Biometric data on Chrome OS is encrypted at rest and sandboxed in various ways to prevent unauthorized access via software. Note that hardware attacks that require physical access, such as opening the case, are not in scope.
The Chrome OS lock screen protects running user sessions from unauthorized access from casual local attackers. We are rewarding research that demonstrates ways to circumvent the lock screen—for example, attacks that leak information from the locked user session or manipulate session state. Note that hardware attacks (such as cold boot attacks) that require opening the case or aren't practical for a casual attacker are not in scope.
|High-quality report with proof of concept/exploit||High-quality report||Baseline|
|Sandbox Escape, Firmware, and Biometric Data||$30,000||$20,000||Up to $15,000|
|Lockscreen bypass||$5,000 - $15,000|
|Chrome OS Persistence||$5,000 - $15,000|
Chrome Fuzzer Program
The Chrome Fuzzer Program allows you to run fuzzers on Google hardware at Google scale across thousands of cores. You receive 100% of the reward value for any bugs found by your fuzzer plus a bonus $1,000, provided the same bug was not found by one of our fuzzers within 48 hours. There are two ways to participate:
LibFuzzer allows fuzz testing of individual components in the Chrome browser, and libFuzzer-based fuzzers are just as easy to write as unit tests. Any Chromium contributor can submit them to the Chromium codebase, which will be picked up and run continuously at scale by our fuzzing automation system, ClusterFuzz.
Fuzzers can also be written to use ClusterFuzz directly. This allows fuzzers to be written in a wide range of languages and to take advantage of ClusterFuzz's more advanced options. Previously this was only available to members of the Trusted Researcher Program but is now open to all.
Before being submitted, fuzzers using either method must:
- Test features shipping in production code that are susceptible to malicious user input.
- Have found at least one vulnerability in local testing and reported in Chromium tracker.
To submit a fuzzer, please provide us with a few details.
If you have a fuzzer running as a part of Chrome Fuzzer Program, you will not receive a reward if one of our fuzzers finds the same bug within 48 hours, as Clusterfuzz may have simply scheduled your fuzzer before ours.
All fuzzers run at Google's discretion.
Frequently asked questions
Q: How can I maximize the potential reward for my report?
A: Our lowest reward for eligible bugs is $500. If the rewards panel finds the bug particularly severe, the value can be higher than what is listed above in the table. To improve your chances, please adhere to the guidelines provided in Reporting Security Bugs.
Q: How do I find out if my bug is eligible?
A: Externally reported bugs are automatically considered for reward once they have been fixed, at which point you will see the "reward-topanel" label added to your bug, indicating it will soon appear at a reward panel meeting. The bug will be updated again once the panel has made a decision.
Q: What happens if I disclose the bug publicly before you had a chance to fix it?
A: Please read our stance on vulnerability disclosure. In essence, our pledge to you is to respond promptly and fix bugs in a sensible timeframe—and in exchange, we ask for a reasonable advance notice. Reports that go against this principle will usually not qualify, but we will evaluate them on a case-by-case basis.
Q: I wish to report an issue through a vulnerability broker / someone not you. Will my report still qualify for a reward?
A: We believe that it is against the spirit of the program to privately disclose the flaw to third parties for purposes other than actually fixing the bug. Consequently, such reports will typically not qualify.
Q: What if somebody else also found the same bug?
A: Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.
Q: What about bugs present in Google Chrome but not the Chromium open source project?
A: Bugs in either build may be eligible. In addition, bugs in plug-ins that are shipped with Google Chrome by default (e.g. PDFium, Adobe Flash) are usually eligible. Bugs in third-party plug-ins and extensions are ineligible.
Q: Do I still qualify if I disclose the problem publicly once fixed?
A: Yes, absolutely, once the bug has been released to users on our Stable channel. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes.
Q: What about bugs in channels other than Stable?
A: We are interested in bugs in the Stable, Beta and Dev channels because it's best for everyone to find and fix bugs before they are released to the Stable channel. However, we discourage testing against canary or trunk builds, because they don't undergo release testing and can exhibit short-lived regressions that are typically identified and fixed very quickly.
Q: What about bugs in features that aren't enabled by default?
A: Features are often developed behind a flag which isn't enabled by default. Reporting security bugs in such code helps ensure users are protected when the feature is enabled. However reporters should be aware that we will likely not reward if we are confident we would have fixed the issue without the report before the feature is enabled.
As of August 2020 an example of a feature not enabled by default is XFA in PDFium. The feature is not enabled and there is a project underway to transition the XFA codebase onto the "Oilpan" Garbage Collector Library. Bugs in XFA which would not be exploitable once that project is complete would likely not be rewarded.
Q: What about bugs in third-party components?
A: These bugs are often eligible (e.g. libxml, image libraries, compression libraries, etc). As long as they can manifest through or affect Chrome, bugs may be eligible even if they are caused by components of the operating system or standard libraries. We're interested in rewarding any information that enables us to better protect our users. In the event of bugs in an external component, we are happy to take care of responsibly notifying other affected parties.
Q: Can you keep my identity confidential from the rest of the world?
A: If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However, at your discretion and if you ask us before the bug is mentioned in release note, we can credit the bug to "anonymous" though note there still may be identifying information in the bug.
Q: Can I submit my report(s) now and provide a working exploit later? Is there a time limit for submitting an exploit?
A: Most definitely! We encourage this approach as it allows us to work on fixing the bugs as soon as possible. It also minimizes the chance that someone else reports the same issue while you're working up an exploit. Although we don't have a set time limit, we would expect that the exploit would follow within a few weeks of the initial report. Exploits submitted outside of this time frame are unlikely to be rewarded. In case of multiple bugs being involved, they all should be reproducible on a single revision.
Q: What is the Trusted Researcher program? Can you run my fuzzer for me?
A: The Trusted Researcher program is now part of the Chrome Fuzzer Program.
The easiest way to get an invite into this program is to submit quality bugs that are found with one of your fuzzers. If we like what we see, we’ll reach out with the details!
Q: Are bugs found by my Chrome Fuzzer Program fuzzer eligible for New Feature Special Reward amounts?
A: Only if the fuzzer specifically targets the new feature and was submitted to us during the New Feature Special Reward time period and finds in-scope bugs, as defined above. Otherwise bugs will be considered at the usual reward levels.
Q: What about full-chain exploits on platforms other than Chrome OS?
A: We are interested in full-chain exploits against Chrome running on other platforms. For example and referring to the table above, a high-quality full-chain exploit that escapes the sandbox on non-Chrome OS platforms would likely receive at least $40,000 ($30,000 for the sandbox escape portion, $10,000 for the code execution in the renderer). In addition, any other bugs in the operating system that can manifest through Chrome are likely to be rewarded as well.
Q: Will Google reward for bugs that are not specifically listed in the table above?
A: Yes. We're interested in rewarding any information that enables us to better protect our users. All of our reward amounts are based on the quality of the report and the security impact of the bug.
Q: You recently changed the reward amount guidelines but my bug was rewarded under the old ones, will you pay the difference to the new amount?
A: I'm afraid not. We reward based on the rules that were in effect at the time of bug submission.
Q: The underground market / my friend Eve pays more for my bugs! Do these comparatively low reward levels encourage the sale of bugs to people in trenchcoats and dark sunglasses?
A: We understand that there are dark corners of the Internet that may pay you more money to purchase any vulnerabilities that you find or exploits that you develop. These people buy vulnerabilities and exploits for offensive purposes to target other users on the Internet. We believe that the reward you get under those circumstances comes with strings attached - including buying your silence and accepting that any bug you sell may be used to target other people without their knowledge. We understand that our cash reward amounts can be less than these alternatives, but we offer you public acknowledgement of your skills and how awesome you are, a quick fix, and an opportunity to openly blog/talk/present on your amazing work (while still offering you a very healthy financial reward for your work!). Also, you'll *never* have to be concerned that your bugs were used by shady people for unknown purposes.
Q: When will I receive my reward?
A: Once the bug has been updated with news of a reward, please wait for a member of the Google Finance team to reach out to coordinate your payment information, usually about a week after the bug has been updated with details of a reward. Once you've been enrolled, you should receive payment in 2 to 4 weeks.
Q: I think the Panel rewarded my report incorrectly?
A: Please reach out to us at firstname.lastname@example.org detailing why you think we should reassess your report.
Q: Can you clarify the differences between the reward categories mentioned in the table above?
A: Sure! More information about the categories and examples please can be found here.
Q: What about Site Isolation rewards?
A: More information on Site Isolation rewards can be found here.
Q: Have a security-related question that was not listed here?
A: Take a look at the Chrome Security FAQ to see if your question is answered there.
We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. 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 depending upon your local law.
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.
Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.