Chrome Vulnerability Reward Program Rules

ATTENTION As of 4 February 2024, Chromium has migrated to a new issue tracker, please report security bugs to the new issue tracker using this form.

Please see the Chrome VRP News and FAQ page for more updates and information.


The Chrome Vulnerability Reward Program rewards the contributions of security researchers who invest their time and effort in helping us to make Chrome Browser more secure. Through this program, we provide monetary awards and public recognition for vulnerabilities responsibly disclosed to the Chrome Browser project.

Scope of program

Any security bug in Chrome Browser may be considered. It’s that simple!*

* Well, it's almost that simple. Important 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. Reports of bugs in new code in trunk may collide with ongoing engineering work as part of "trunk churn."

    • Reports for security bugs introduced in newly landed code on trunk / head within the last 48 hours are not eligible for VRP rewards.
    • VRP eligibility for security bug reports based on newly introduced bugs in trunk / head will be based on assessment of ongoing development and discussion with the team to determine if the VRP report was indeed used in identifying and fixing the bug.
    • Reports for issues resulting from newly landed commits on head that are seven (7) or fewer days old are not likely to be eligible for a VRP reward. For example, bugs found though fuzzing are very unlikely to be rewarded if they are less than seven days old, as it is likely and often the case that our internal fuzzers have also discovered them.
  • 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. If these bugs are in a project or product maintained outside of Google, they should be reported - by you - upstream to that project or vendor in parallel to reporting them to us. This ensures you have visibility to the status of the fix, receive credit for the discovery, and we are not brokering bugs on your behalf. Bugs not reported upstream may not be eligible for a full reward. Particularly, bugs in WebKit that impact Chrome on iOS may not be eligible for a VRP reward if they are not reported upstream to Apple.

    • This also includes GPU driver bugs that are reachable from a renderer process and triggerable through Chrome Browser, such as user mode GPU driver bugs in Mesa or Mali drivers. As with all security issues in third-party dependencies, the bug must be reachable and manifest in an active release channel of Chrome, on a supported platform. You should report these issues to the Chromium bug tracker similar to any other security bug report.
  • Bugs in unlaunched features - in code behind a flag not enabled by default - are generally eligible for the full potential VRP reward, with the exception of bugs in V8 features marked as Experimental. These features are part of early and experimental V8 development efforts and introduce a known stability and security risk. Security bugs that are specific to V8 Experimental features are not eligible for Chrome VRP rewards. The experimental status of a V8 feature will be denoted in the flag definition in source code, in the flag description in the help menu, and via a printed message at runtime.

  • Beginning in Chrome 118, MiraclePtr was enabled in non-renderer processes across all active release channels of Chrome. MiraclePtr has been enabled in Fuchsia beginning in 128. As of Chrome 128, MiraclePtr-protected bugs are no longer considered security issues and are not in scope for VRP rewards.

    • We are very interested in research of bypasses of MiraclePtr protection, resulting in exploitation of and RCE from a vulnerability that is protected by MiraclePtr. Reports of a MiraclePtr bypass are eligible for a potential $100,115 reward. A demonstration of exploitation of a BRP-protected use-after-free (UAF) through a report of a novel UAF with PoC or exploit is eligible for additional rewards. The MiraclePtr bypass reward is detailed in the Additional Chrome Rewards section below.
    • A vulnerability is protected by MiraclePtr only when the test case triggering it results in a status of "MiraclePtr Status: PROTECTED" when reproduced in an ASAN build. Issues with test cases that result in a status of "MiraclePtr Status: NEEDS MANUAL ANALYSIS" in an ASAN build will be reviewed and handled as potential security issues. If, during the course of triage and investigation, the bug is deemed to be BRP protected, it will be downgraded to a bug and handled as a functional issue and would not be eligible for a VRP reward.

Qualifying vulnerabilities

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 actionable report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed actionable bug report in the bug tracker is generally considered the first report. Please see the below subsection Update to policy regarding unactionable reports and duplicates. for more information.
  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 coordinated 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.

Update to policy regarding unactionable reports and duplicates

To incentivize more complete and actionable reporting, the date and time a report is submitted in the bug tracker will not be the sole factor for determining whether a report is considered the first report of that security issue.

A report is considered an actionable submission when the actionable information required to triage is provided in the report. Examples of actionable information include a test case / PoC, steps to reproduce, or other demonstration of the security issue being reported. If a report lacks this actionable information, the original report's timestamp will not be used when considering it in the context of duplicate reports. This means that an earlier- received incomplete submission may be marked as a duplicate of a later received actionable submission. The later-received, actionable report will be considered the canonical report of that security issue. If a report lacks actionable information that is needed to reproduce, such as a PoC, steps to reproduce, a symbolized stack trace, or other evidence of the security issue, the time of submission will be based on when the actionable information is received instead of the timestamp of the original report.

This does not mean we won't attempt to triage a report based on the information we receive, but if the report is lacking sufficient information for triage at the time a Security Shepherd is handling the report and another report with actionable information is received before the earlier report can be fully triaged, we may move forward with the actionable report. The first-received report will not be considered "first in", and instead will be considered a duplicate of the actionable report. The later-received, actionable report will be the one considered by the VRP Panel for a potential reward.

This policy additionally applies to reports with PoCs that cannot be reproduced, non-minimized test cases, and reproduction steps that do not result in demonstrating the issue being reported without follow-ups from the reporter to provide new, actionable information that would result in successful reproduction (e.g. which platform is being used, or flags that must be enabled to trigger the issue). If a report solely contains artifact or information that is not actionable and we cannot effectively triage the report, the report is not considered an actionable submission at that time. Security Shepherds will still utilize the Needs-Feedback function in the bug tracker and request more information, but the report is not considered actionable until that required information or artifact has been provided.

This policy is also applicable to shell reports, i.e. reports submitted without any information to gain a hold or timestamp at an earlier than actionable time. The report is not considered an actionable submission until it consists of at least some or most of the characteristics consistent with a baseline-quality report.

If the first submission of a report is considered actionable and can be resolved based on the contents of the report, it will always be considered the first and canonical report of that security issue (even if it is not a high-quality report). Once an issue has been disclosed, requests to the Chrome VRP Panel to assess a duplicate report for VRP reward because it is a higher quality report than the original will not be considered.

Duplicate reports

Traditionally our policy related to duplicates has been strictly: "the earliest filed bug report in the bug tracker is considered the first report." Often we receive later versions of an earlier-reported security bug that are of such high quality that we use those components in advancing the triage or resolution of that issue. While this is against the core foundations of our policy around duplicate reports, we have made numerous exceptions and issued a small reward to the later reporter for their contributions that result in getting the security issue resolved.

The Chrome VRP wants to better acknowledge and consistently reward these contributions. When a later-submitted report is of higher quality and is actively used by the security team or engineers to improve triage, reproduction, investigation, or root cause analysis of an earlier-reported issue, both reports may be eligible for the VRP reward -- with the total reward amount being divided between the two reports.

This policy will only take effect when the security or engineering teams have actively used or acknowledged artifacts from a duplicate report to work toward resolution of a security issue. This policy is not applicable based solely on the existence of a duplicate report submitted in the same general period of time.

Investigating and reporting bugs

All security 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.

The 'SecurityEmbargo' hotlist can be applied to reports that should never be publicly disclosed. As Chromium is open source and bug reports are used by embedders for patch and contribution decisions, we aim to be as transparent as possible with our security bugs at the appropriate times of disclosure. The 'SecurityEmbargo' hotlist restricts this transparency indefinitely and should be used judiciously and rarely.

Requests to apply the 'SecurityEmbargo' hotlist will need to be presented with specific justifications explaining the necessity of this request. Please note, your full email address is obscured by default in the Chromium bug tracker and is not revealed once the bug is publicly disclosed, regardless of 'SecurityEmbargo' hotlist. If you would like to confirm this setting, navigate to your username in the upper right corner of the bug tracker and click the arrow > Settings > User Settings > Privacy and ensure the 'when I participate in projects, show non-members my email address as "$elided email address" instead of the full email address' option is selected.

If you would like to use a new email address for submitting security bugs, this new one can be associated with your existing accounts in our database and VRP payment system.

Reward amounts

The two tables below outline the standard reward amounts for the most common classes of security bugs. Keep the following points in mind:

  • To be eligible for the full reward amount in these tables, the issue MUST be:
    • Web accessible, i.e. it can be triggered by remote content.
    • Not mitigated, i.e. does not require user interaction, installing an extension, or being triggered by browser shutdown, or profile destruction. Please see the Reward Amounts for Mitigated Security Bugs section for specific reward amounts and details.

All reports should provide a convincing explanation or evidence of exploitability (such as through a PoC) and/or ordered reproduction steps rather than consisting mainly of static code analysis.

  • High-quality reports MUST:
    • Be reliably reproducible: We must be able to efficiently and readily reproduce the issue based on the test case or other information provided in the report.
    • Consist of a minimized test case / proof of concept (PoC).
    • Provide the full symbolized ASAN stack trace (if applicable).
    • Provide clear, concise, and ordered steps to reproduce.

Memory corruption vulnerabilities

High-quality report with demonstration of RCE High-quality report demonstrating controlled write High-quality report of demonstrated memory corruption Baseline
Sandbox escape / Memory corruption / RCE in a non-sandboxed process [1], [2] Up to $250,000 Up to $90,000 Up to $35,000 Up to $25,000
Memory Corruption / RCE in a highly privileged process (e.g. GPU or network processes) [2] Up to $85,000 Up to $70,000 Up to $15,000 Up to $10,000
Renderer RCE / memory corruption in a sandboxed process Up to $55,000 Up to $50,000 Up to $10,000 Up to $7,000 [3]

[1] Also includes the GPU process on Android. RCE in the Android GPU process is considered a sandbox escape since the GPU process is not sandboxed on the Android platform.

[2] Amounts are based on the precondition of a compromised renderer, otherwise the equivalent renderer reward will also be added.

[3] Reports of renderer OOB reads or DCHECK / SEGV / etc. bugs in V8, without demonstration of write or RCE, are only eligible for baseline reward amounts.

Reports must meet all criteria defined above and in the Report Quality section to be considered a high-quality report. Reward ranges for the above table are defined as follows:

  • High-quality report with demonstration of RCE: Report clearly demonstrates remote code execution, such as through a functional exploit.
  • High-quality report demonstrating controlled write: Report clearly demonstrates attacker controlled write of arbitrary locations in memory; reports demonstrating an arbitrary write to an attacker controlled address with an attacker controlled value in the renderer quality for the renderer RCE reward.
  • High-quality report of demonstrated memory corruption: Report of demonstrated memory corruption in Chrome that consists of all the characteristics of a high-quality report.
  • Baseline: A report consisting of a stack trace and PoC displaying evidence that memory corruption is triggerable and reachable in Chrome.
  • Below baseline: (not shown) Reports that do not consist of the characteristics of a baseline reward will not be eligible for reward amounts in this table and are only eligible for reduced rewards. A report that does not demonstrate a security bug that is reachable in and manifests in Chrome may not be eligible for a Chrome VRP reward.

Memory Corruption: Access to a value versus the potential for RCE

We encourage all reports of memory corruption in Chrome and consider them eligible for a VRP reward. In cases where a report displays an out-of-bounds read or access to a value without demonstrating a write or the potential for attacker control of that value or RCE, these issues may be considered for a lower reward amount, consistent with an information disclosure.

If a memory corruption issue can be exploited to result in an OOB write or attacker control of the value, enabling RCE, please ensure that this is demonstrated in your report.

Other vulnerability classes

For these classes of bugs, high-quality reports are expected to clearly demonstrate the exploitability and impact to a user, such as a convincing UI spoof or how user information would be disclosed.

High Quality && High Impact [1] High Quality && Moderate Impact [1] Baseline || Lower Impact
UXSS || Site isolation bypass Up to $30,000 Up to $20,000 Up to $10,000
Security UI spoofing Up to $10,000 Up to $5,000 Up to $3,000
User information disclosure Up to $25,000 Up to $10,000 Up to $2,000
Local privilege escalation [2] Up to $15,000 Up to $5,000 Up to $2,000
Web platform privilege escalation Up to $7,000 Up to $4,000 Up to $1,000
Exploitation mitigation bypass Up to $5,000 Up to $4,000 Up to $1,000

[1] Reports of a vulnerability in any of these classes must consist of a functional demonstration of the bug reported and a PoC to be considered a high quality report.

[2] Valid reports of LPE vulnerabilities should demonstrate exploitability that breaks an OS security boundary using a Chrome component and is otherwise within Chrome's threat model.

Reward amounts for security bugs in these classes will be determined based on report quality and bug impact:

Bugs with significant preconditions to exploit and no demonstrable risk to a user are not eligible for a Chrome VRP reward. In addition, the Chrome VRP Panel reserves the right to decline a reward for low-quality and speculative reports.

Reward amounts for mitigated security bugs

Mitigated security bugs are eligible for VRP rewards, but at a reduced reward amount.

We have defined levels for mitigated security bugs accordingly:

  • Mildly mitigated: Security bug with minimal mitigations; e.g. a security bug reliably triggered by two or fewer standard user interactions OR winning a race condition; does not require profile destruction or shutdown to trigger
  • Moderately mitigated: Security bug with multiple mitigations; e.g. a malicious extension combined with user interaction or other mitigation, or winning a race condition combined with another mitigation
  • Highly mitigated: Security bug with multiple types of mitigations or triggered by a series of steps; e.g. a security bug triggered by a series of user interactions or involving a non-standard/unlikely workflow
    • A use-after-free protected by BackupRefPtr / MiraclePtr is considered to be highly mitigated.
  • Substantially mitigated: A heavily mitigated security bug, not likely to be able to be exploited in a real-world scenario; e.g. a bug requiring a series of implausible user interactions – such issues are not generally considered security issues and may not be eligible for a VRP reward.

The standard reward amounts for mitigated security bugs are as follows:

Mildly Mitigated Moderately Mitigated Highly Mitigated
Sandbox escape / Memory corruption in a non-sandboxed process $5,000 - $10,000 $3,000 - $4,000 $1,000 - $2,000
RCE / Memory Corruption in a sandboxed process $3,000 Up to $2,000 Up to $1000

Rewards apply to Chrome Browser on supported platforms, including Windows 7+, macOS 10.13+, Linux, Android 4.4+, iOS 7+, and the current versions of ChromeOS, Fuchsia, and Lacros.

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.

Reports that do not meet the criteria for a baseline report do not provide sufficient detail to help developers rapidly address the security vulnerability. While these reports will still be evaluated for a potential VRP reward, they will receive significantly reduced reward amounts. If there is no evidence of exploitability before the issue is resolved or goes to the VRP panel, the report may not be eligible for a VRP reward.

Reassessment of Reward Amount

If you believe there was an error in the VRP's reward decision, we are happy to reassess for a potential change in VRP reward amount.

While new information is appreciated and encouraged, and is considered in the assessment, please take care to provide all details and full information in the original report or before/during the triage process. This ensures a more efficient triage and pathway to a fix. Core details about the vulnerability provided after the root cause has been identified may result in a substantially lower VRP reward.

Reward Donation Option

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.

Report Quality

A high-quality report with a functional exploit is a report with the characteristics of a high-quality report (as described below), but also includes a reliable exploit that demonstrates that the bug can be easily, actively, and reliably used against Chrome users.

High-quality reports typically have several of these characteristics:

  • Minimized test case
  • Demonstrate exploitability of the bug presented
  • Analysis to help determine the root cause
  • Concise and well-written with only necessary detail and commentary
  • Clear steps to reproduce with reliable reproduction
  • Timely responses to questions from the security team or engineers fixing the bug
  • Suggested patch
  • Bisect (identification of the commit or commit range that introduced the bug)

Baseline reports should contain at least some/most of the following:

  • Minimized test case or output from a fuzzer that highlights a security bug is present
  • The versions of Chrome affected by the bug
  • Symbolized stack trace
  • Proof of concept (PoC) and/or clear, concise reproduction steps

Reports should not:

  • Provide only a crash dump
  • Provide a stack trace without symbols
  • Be submitted without a Proof of Concept (PoC) or only provide a poor-quality PoC (e.g. a large fuzz file dump with no attempt at reduction)
  • Simply suggest a theoretical or potential vulnerability based solely on static code analysis

Reports that consist of the above may not qualify for VRP rewards.

Less convincing or more constrained bug submissions will likely qualify for reduced reward amounts, as chosen at the discretion of the reward panel.

Report criteria for reward decisions

Chrome VRP reward decisions are made after the bug is fixed. This is, in part, to allow reward decisions to be based on the totality of the security impact of the issue demonstrated by the reporter and information used in investigation and resolution of the bug.

Unless there are exceptional circumstances, Chrome VRP reward decisions are based solely on the information provided in the original report before the complete resolution of the issue reported.

Information provided after the bug is fully resolved or after the reward decision has been made will not be eligible for a reassessment of the reward decision. The primary exception are functional exploits demonstrating RCE for a given bug, which will continue to be accepted for a higher reward after fix and Chrome VRP reward decision.

As always, we do have an open reassessment policy based on information or subtext we may have overlooked or incorrectly analyzed in our original assessment. Entirely new information, such as a POC that demonstrates the exploitability of a bug with fewer mitigations that does not contribute to the RCA or fix of the bug, will not be eligible for a higher reward.

Additional Chrome Rewards

Reports may be eligible for additional bonus rewards if they meet the conditions outlined in this section.

Bonus reward amounts
Bisect bonus $500-$1,000 (see the Bisect Bonus section)
Patch bonus $500 - $2,000 (see the Patch Bonus section)
Fuzzer bonus Up to $5,000 (see the Chrome Fuzzer Program section)

Bisect Bonus

On top of the standard reward amounts, we offer a bisect bonus:

  • $500: For identifying, such as through reproduction or other evidence, the earliest major release or oldest active release channel impacted by the vulnerability
  • $1,000: For identifying the specific commit that introduced the bug

Patch Bonus

On top of the standard reward amounts, we offer a patch bonus: A well-written and accepted patch provided with the report is eligible for a patch bonus of $500 - $2000. 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.

Fuzzer Bonus

The Chrome Fuzzer Program allows you to run fuzzers on Google hardware at Google scale across thousands of cores.

You will receive 100% of the reward value for any bugs found by your fuzzer, plus a fuzzer bonus, provided the same bug was not found by one of our fuzzers within 48 hours.

Fuzzer bonuses are tiered as follows:

  • Renderer/sandboxed process bugs found by fuzzer: baseline reward + $2,000 fuzzer bonus
  • GPU process bugs found by fuzzer: baseline reward + $3,000 fuzzer bonus
  • Browser/non-sandboxed process bugs found by fuzzer: baseline reward + up to $5,000 fuzzer bonus

Please see the Chrome Fuzzer Program section for more details about the Chrome Fuzzing Program.

MiraclePtr Bypass Reward

Code and issues in code protected by BackupRefPtr / MiraclePtr are expected to be resilient against the exploitation of UAFs in non-renderer processes. We no longer consider MiraclePtr-protected UAFs in non-renderer processes to be security bugs, but stability issues, as of M128. A valid bypass of MiraclePtr is now eligible for a reward of $250,128.

Eligible bypass submissions should consist of the following:

  1. Link to the original issue or patch (if not yet publicly disclosed), if not a novel UAF. Otherwise provide a full report of the MiraclePtr-protected security bug

  2. Test case / PoC triggering the issue that demonstrates protection under BRP-ASAN with a MiraclePtr status of PROTECTED

  3. PoC that demonstrates the second-order primitive in the release build (controlled write or instruction pointer control)

  4. Complete, detailed write-up of the technique to bypass MiraclePtr

Please note: the possibility of direct use of the zapped memory value ("\xef" bytes) during a UAF (e.g. as an enum value or size) is known and not itself considered a novel technique, and is not eligible for this bypass reward.

We are interested to see examples of this technique being applied, and instead offer a reward of $70,000 - $90,000 for a novel PoC demonstrating a second-order primitive by applying this technique to a Miracle-Ptr protected issue, depending on the process. A novel demonstration presented with a functional exploit is eligible for a reward of $85,000 - $250,000.

A bypass report must specifically explain or demonstrate how existing MiraclePtr protections can be bypassed. A UAF in a non-renderer process is only protected by MiraclePtr when the test case / PoC triggering it results in a status of "MiraclePtr: PROTECTED" when reproduced in a Chrome ASAN build. If the MiraclePtr status in ASAN output is NOT PROTECTED or MANUAL ANALYSIS REQUIRED, these issues are not considered protected by MiraclePtr and are not eligible for the bypass reward. Reports of UAFs in non-renderer processes that involve pointers not protected by MiraclePtr are eligible for the standard Chrome VRP reward amounts for that bug class, based on report quality and mitigations.

If a complete, eligible bypass submission includes a novel UAF in a non-renderer process process, through which the bypass can be clearly and concisely demonstrated through a PoC or exploit, the $250,128 reward amount will be added as a bonus to the reward amount for the non-renderer process UAF. In this scenario, a novel UAF bug that demonstrates a MiraclePtr bypass is submitted with a functional exploit is eligible for a reward up to $85,000-$250,000 - in addition to the $250,128 bonus for the submission of an eligible bypass.

V8 Sandbox Bypass Rewards

The V8 Sandbox is a lightweight, in-process sandbox for V8 designed to mitigate common V8 vulnerabilities.

Since the V8 sandbox bypass was introduced into the Chrome VRP scope in April 2024, eligible reports of V8 sandbox bypasses were restricted to specific and strict submission criteria. While the V8 sandbox is still not yet considered a full security boundary, it has been the intent from the start to expand the scope of V8 sandbox bypass rewards and relax submission rules as the sandbox matures.

As of November 2024, we are expanding the scope of the V8 sandbox bypass rewards to include all memory corruption demonstrated outside the V8 sandbox in Chrome or V8.

Valid submissions must demonstrate memory corruption outside the V8 sandbox in any current, active release channel build of Chrome or d8, with a demonstrated controlled write outside the sandbox being eligible for a higher reward.

Demonstration of...
Memory corruption outside the V8 sandbox $5,000
Controlled write outside the V8 sandbox $20,000

To be eligible for these rewards:

  • A test case must be provided.
  • The V8 sandbox must be enabled by using v8_enable_sandbox = true in the gn args on a device using the 64-bit configuration of Chrome.
  • The reproduction should make use of the memory corruption API(v8_enable_memory_corruption_api = true) which provides read and write access inside the sandbox.

Your submission may make use of --expose-gc, --single-threaded, --fuzzing, --jit-fuzzing, and/or --allow-natives-syntax, but otherwise cannot make use of any additional flags. The reproducer will then be executed with --sandbox-testing, which will indicate whether memory corruption outside the sandbox has been detected. For more information, see the sandbox readme.

Submissions should be reported using the Chromium security bug reporting form. The report title should start with "V8 Sandbox Bypass:". The report will not be triaged by the Chrome Security team, other than to be handed off directly to the V8 Security team.

Once the bypass has been resolved and the issue closed as Fixed, the report will go to the Chrome VRP for reward decision via the standard Chrome VRP processes. See the Chrome VRP FAQ for more information about Chrome VRP policies or processes.

Previous sandbox submissions under the previous scope have been opened for public disclosure. Please ensure your submission is not a duplicate of a known issue and feel free to learn from previous bypass submissions in the Chromium bug tracker.

Rewards for V8 Bugs in Stable Channel and Older Versions

Reports of security bugs in V8 which impact Stable channel and older versions of Chrome may qualify for increased reward amounts, as specified in the table below. Stable channel impact of a given issue must not have been achieved simply due to a recent field experiment / Origin Trial or flag definition change.

To be eligible for these increased reward amounts, the report of the V8 bug should include a bisection to help validate the age / version of Chrome the bug was introduced in. The report must clearly describe through analysis or demonstrate exploitability of the bug being reported.

As always, the bug must not be previously reported or already known to us to be eligible for these reward amounts.

High-quality report
Renderer RCE / Memory Corruption in a Sandboxed Process Up to $20,000

V8 security bugs older than M105 may be eligible for a reward higher than specified in the table, based on the age of the bug.

The following are some examples of how a report could demonstrate that exploitation is possible, but any analysis or proof of concept will likely be considered by the panel:

  • Executing shellcode from the context of chrome or d8
  • Creating an exploit primitive that allows arbitrary read 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

See issues 914736 and 1076708 for examples of reports that do this.

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 (see the Fuzzer Bonus section), provided the same bug was not found by one of our fuzzers within 48 hours.

The Chrome Fuzzer Program is not accepting ClusterFuzz fuzzers at this time. New libFuzzer in-tree fuzzers can still be submitted, as specified below. Valid security bugs reported from previously submitted and accepted fuzzers are still eligible for VRP rewards and fuzzer bonuses.

libFuzzer

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.

ClusterFuzz

New ClusterFuzz fuzzers are not being accepted at this time. This section will be updated when this changes.

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

The Chrome VRP FAQ has a new home. Please find the FAQ, as well as security bug reporting best practices, and other news and helpful information on the Chrome VRP News and FAQ page.

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.

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.

Summary Changelog

This section provides a summarization of changes made to the Chrome VRP policies and rewards structure.

  • 2024-11: Minor updates to third-party bug scope, report quality / report characteristics for reward decision, and flags used in valid V8 sandbox bypass submissions
  • 2024-11: Updates to V8 sandbox bypass scope and rewards
  • 2024-08: Major update to reward categories and amounts - updated bug and reward categories and reward amounts; separated main (non-mitigated) reward table into memory corruption and other vulnerability classes, updated categories and reward amounts in both tables; moved bonus reward amount information to Additional Chrome Rewards section
  • 2024-07: Updated policy to reflect that MiraclePtr / BRP-protected bugs are no longer considered security issues as of 128; updated V8 bugs >= Stable channel bonus to remove expiry date
  • 2024-04: Removed expired Full Chain Exploit Bonus; added V8 Sandbox Bypass Rewards
  • 2024-03: Updated Rewards for V8 Bugs in Stable Channel or Older Versions