Chrome Reward Program Rules
The Chrome 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:
- 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.
- 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 responsible disclosure is a two-way street; it's our duty to fix serious bugs within a reasonable time frame.
- If you have a fuzzer running as part of our Chrome Fuzzer Program, you will not receive a reward if one of our fuzzers finds the same bug within 48 hours.
Rewards for qualifying bugs typically range from $500 to $100,000.
We have a standing $100,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
functional exploit 
|High-quality report ||Baseline ||Low-quality report |
|Sandbox Escape ||$15,000||$10,000||$2,000 - $5,000||$500|
|Renderer Remote Code Execution||$7,500||$5,000||$1,000 - $3,000||$500|
|Universal XSS (local bypass or equivalent)||$7,500||$5,000||N/A||N/A|
|Information Leak||$4,000||$2,000||$0 - $1000||$0|
|Download Protection bypass ||N/A||$1,000||$0 - $500||$0|
|New Feature Special Rewards||See below|
 A high-quality report with a reliable exploit that demonstrates that the bug
reported can be easily, actively and reliably used against our users.
 A report that includes a minimized test case and the versions of Chrome affected by
the bug. You will also demonstrate that exploitation of this vulnerability is very likely
(e.g. good control of EIP or another CPU register). Your report should be brief and well
written with only necessary detail and commentary.
 A minimized test case or output from a fuzzer that highlights a security bug is
present without establishing that the issue is exploitable.
 A report submitted with only a crash dump, without a Proof of Concept (PoC) or with
a poor quality PoC (e.g. a 1MB fuzz file dump with no attempt at reduction) that is later
verified to be a legitimate issue.
 Escaping any layer of the sandbox (including the NaCl sandbox) will be considered as
a sandbox escape.
 Landing a blacklisted test binary (malware example, UwS example) on disk where a typical
user could execute it, on Mac or Windows. The file type on disk must lead to non-sandboxed
code execution after minimal user interaction with the file. See the FAQ below for more
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
Rewards apply to Chrome on Win 7+, MacOSX v10.9+, Linux, Android 4.4+, iOS 7+ and to
current versions of Chrome OS. We are also interested in bugs that affect Chrome on
Windows XP and Vista, which may qualify for a reduced reward amount.
On top of these rewards, we offer either $500 or $1,337 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
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 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 an established charity. 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.
Investigating and reporting bugs
All bugs should be reported via this form. 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 answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed to Google Help Centers.
Chrome New Feature 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 special rewards
Site Isolation ensures that each site (combination of scheme and eTLD+1) runs in its own OS process, and provides mitigation of speculative side channel attacks. It is enabled by default on Chrome 67 and above on desktop platforms.
- 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 CORB-eligible responses not to be blocked. This includes HTML, XML, and JSON responses that have nosniff headers, assuming sites operators have taken the necessary steps.)
Out of scope / known issues:
- Attacks that assume a compromised renderer. Site Isolation's threat model excludes such attacks at present. (Future development of Site Isolation will provide defense against such attacks.)
- Known issue whereby hosted apps share processes with each other.
- Note that a small percentage of users may be opted out of Site Isolation to provide a
control group. Researchers should ensure the feature is enabled by using the
--site-per-processcommand line flag.
Duration: Bugs reported via this form between July 11th 2018 and January 11th 2019 will be considered for Site Isolation special rewards.
|High-quality report with proof of concept/exploit ||Baseline |
|Site Isolation Special Reward||$5,000 - $8,000||$500 - $3,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
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 $500, 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 are just as easy to write as unit tests. Any Chromium contributor can submit libFuzzer tests to the Chromium codebase, which will be picked up and run 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.
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 date, we've given out several instances of rewards $30,000 and higher. 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 coordinated 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. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and the rewards Hall of Fame.
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 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 bug 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.
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: Why are these rewards significantly less than the old Pwnium?
A: The prizes at Pwnium were large (up to $150,000) because Pwnium has significant restrictions as a competition. Former Pwniums required a physical presence at the competition location, a successful demonstration of your exploit on a future version of Chrome and the delivery of a full-chain exploit via a webpage - all while doing this on one of our latest Chromebooks in a short time window in March!
Even if you had a bug that met all of these criteria, you still ran the risk of Google fixing the bug before Pwnium or someone else reporting the issue to us if you chose to wait for the competition. As we build a more secure browser, we believe that Pwnium-style bug-chains will be significantly harder to come by, as evidenced by the handful of people who entered that competition.
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 $22,500 ($15,000 for the sandbox escape portion, $7,500 for the code execution in the renderer). In addition, any other bugs in the operating system that can manifest through Chrome are highly likely to be rewarded as well.
Q: Can I have more details about the Download Protection bypass rewards?
A: Sure! Here are all of the qualifying rules you need to consider:
- 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
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: The black market / my friend Ned 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 are getting 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.
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.