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. Non-security bugs and queries about problems with your account should be instead directed to Google Help Centers.
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||$5,000 - $15,000|
|Universal Cross Site Scripting||$20,000||$15,000||$2,000 - $10,000|
|Renderer RCE / memory corruption in a sandboxed process||$10,000||$7,500||$2,000 - $5,000|
|Security UI Spoofing||$7,500||N/A ||$500 - $3,000|
|User information disclosure||$5,000 - $20,000||N/A ||$500 - $2,000|
|Web Platform Privilege Escalation||$5,000||$3,000||$500 - $1,000|
|Exploitation Mitigation Bypass||$5,000||$3,000||$500 - $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.
Site Isolation special rewards
From time to time, we may offer increased reward amounts for bugs in newly released or soon to be released features. They will be time-limited, after which bugs submitted will be considered at the usual rates above.
Site Isolation makes it possible for sites (i.e., combination of scheme and eTLD+1) to run in dedicated renderer processes. This can mitigate speculative side channel attacks as well as attacks from compromised renderer processes. Site Isolation is enabled for all sites on desktop platforms. On Android, Site Isolation is enabled for sites where users enter passwords, but it does not yet mitigate compromised renderers.
- Bugs that cause two or more cross-site documents from the web to commit in the same process. i.e. force pre-Site Isolation behaviour.
- Bugs that cause cross-site data disclosure, even if the bug assumes a compromised renderer. Examples of data protected by Site Isolation: cookies, saved passwords, localStorage, IndexedDB, HTTP resources covered by CORB or CORP.
Out of scope and known issues:
- Site Isolation on Android is not enabled for all sites or devices. Reports should work when Site Isolation is enabled for the victim site (e.g., when the victim site is specified in chrome://flags/#isolate-origins).
- Compromised renderers are currently out of scope for Site Isolation on Android reports.
- Sandboxed frames and data: URLs are currently treated as the same site as their creator.
- CORB is not enforced for the Flash plugin, which is disabled by default and will be removed. CORB is also not enforced for a small set of allowlisted extensions, until these extensions have a chance to update to the new security model.
- Compromised renderers can still spoof other sites (e.g., spoof Origin headers or Sec-Fetch-Site headers).
- Timing attacks and cross-site-search attacks are out of scope and may need to be mitigated by robust server-side CSRF protection.
- Problems in websites (e.g. missing CORB protection because of incorrect Content-Type header) or extensions (e.g., privilege escalation via messages from a compromised content script) are out of scope of the Chrome VRP, but may be covered by a separate website-specific or extension-specific VRP.
Examples of in-scope Site Isolation issues:
- Unexpected process sharing: 863069
- Cross-Origin Read Blocking (CORB) bypass: 927849
- Disclosing IndexedDB data to a cross-site renderer process: 917668
Duration: Bugs reported via this form after July 11th 2018 will be considered for the Site Isolation special reward. This program will be reviewed periodically and may be amended or terminated at any time.
|High-quality report with proof of concept/exploit ||Baseline |
|Site Isolation Special Reward||$10,000 - $20,000||$2,000 - $10,000|
 A high-quality report with an exploit that demonstrates that the bug is in
 Other in-scope reports, e.g. if exploitation is heavily mitigated or
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 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.
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 and Firmware||$30,000||$20,000||$5,000 - $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.
Download Protection bypass
Chrome’s Download Protection service protects users from downloading files that are already known to Google’s Safe Browsing service as unsafe. Any mechanism to bypass the download protection checks for files that are already known to be unsafe would be considered eligible for a reward, as long as the conditions listed below are met.
Rules for submitting download protection bypass:
- Safe Browsing must be enabled on Chrome and have an up-to-date database (this may take up to a few hours after a new Chrome install).
- Safe Browsing servers must be reachable on the network.
- Binary must land in a location a user is likely to execute it (e.g. Downloads folder).
- The user can’t be asked to change the file extension or recover it from the blocked download list.
- Any gestures required must be likely and reasonable for most users. As a guide, execution with more than three reasonable user gestures (eg: click to download, open .zip, launch .exe) is unlikely to qualify, but it’ll be judged on a case-by-case basis. The user can’t be expected to bypass warnings.
- The download should not send a Download Protection Ping back to Safe Browsing. Download Protection Pings can be measured by checking increments to counters at chrome://histograms/SBClientDownload.CheckDownloadStats. If a counter increments, a check was successfully sent (with exception to counter #7, which counts checks that were not sent).
- The binary’s hosting domain and any signature can not be on a whitelist. You can measure this by checking chrome://histograms/SBClientDownload.SignedOrWhitelistedDownload does not increment.
- The extension of the binary file must be one of those that Chrome already tracks. This list can be found here: download_file_types.asciipb
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: You will see a provisional comment to that effect in the bug entry once we have triaged the bug or the "reward-topanel" label on your bug.
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 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: Yes. 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 made public, we can credit the bug to "anonymous" and remove identifying information from the bug entry.
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. The updated reward amounts are effective for reports submitted on or after July 18th 2019.Q: The black 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: 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.