bughunters.google.com Open in urlscan Pro
2a00:1450:4001:827::2011  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to Content (Press Enter)




GOOGLE BUG HUNTERS

About

Report

Learn

Leaderboard

Open Source Security

Blog


AnmeldenÜber Google anmelden

menu


GOOGLE BUG HUNTERS


GOOGLE BUG HUNTERS

 * About
   
 * Report
   
 * Learn
   
 * Leaderboard
   
 * Open Source Security
   
 * Blog
   
   
 * 

 * Overview
 * News
 * Key Stats
 * Rules
 * FAQs
   

1showValues


RULES

Android and Google Devices Security Reward Program RulesBonus Awards RulesChrome
Vulnerability Reward Program RulesChromeOS Vulnerability Reward Program
RulesDeveloper Data Protection Reward Program RulesGoogle and Alphabet
Vulnerability Reward Program (VRP) RulesGoogle Mobile Vulnerability Reward
Program RulesGoogle Open Source Software Vulnerability Reward Program
RulesGoogle Play Security Reward Program RulesOpen Source Security Subsidies
RulesOSS-Fuzz Reward Program RulesOur Rewards PhilosophyPatch Rewards Program
RulesVulnerability Research Grant Rules



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.
 * 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 M115, BackupRefPtr (also known as MiraclePtr) is enabled across
   all Chrome platforms (with the exception of iOS, Fuchsia, and CastOS). At
   this time, issues protected by MiraclePtr are considered to be highly
   mitigated security bugs. They are still eligible for VRP rewards, but rewards
   will be consistent with those defined in the highly mitigated category of the
   mitigated security bug rewards table.
   * 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. The first report of a MiraclePtr bypass is 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.


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 table below outlines 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 this table, 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.
 * High-quality reports must be reliably reproducible and consist of a proof of
   concept (POC), symbolized stack trace (if applicable), and steps to
   reproduce.
 * All reports in this section must provide a convincing explanation or evidence
   of exploitability (such as through a POC), and/or numbered reproduction steps
   rather than simply consisting of static analysis of code.

High-quality report with functional exploit High-quality report Baseline Sandbox
escape / Memory corruption in a non-sandboxed process $40,000 [1] $30,000 [1] Up
to $20,000 [1] Universal Cross Site Scripting (includes Site Isolation bypass)
$20,000 $15,000 Up to $10,000 Memory Corruption in a highly privileged process
(e.g. GPU or network processes) $20,000 $15,000 Up to $10,000 Renderer RCE /
memory corruption in a sandboxed process $15,000 $10,000 Up to $7,000 Security
UI Spoofing $7,500 N/A [2] Up to $3,000 User information disclosure $5,000 -
$20,000 N/A [2] 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
Bisect Bonus $500-$1,000 (see the Bisect Bonus section) Chrome Fuzzer Bonus Up
to $5,000 (see the Chrome Fuzzer Program section) Chrome Patch Bonus $500 -
$2,000

[1] Amount based on precondition of a compromised renderer, otherwise the
renderer RCE reward will also be added.

[2] 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 exploit.


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 is demonstrated
in your report.


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.


ADDITIONAL CHROME REWARDS



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 the browser process. The first
valid bypass of MiraclePtr is eligible for a reward of $100,115. Rewards for
subsequent bypass reports will be based on potential mitigations from the first
report of a bypass. Subsequent reports of a bypass may be eligible for the
$100,115 reward if they are novel and complete reports of a bypass.

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 $30,000 for a novel POC demonstrating a second-order primitive
by applying this technique to a Miracle-Ptr protected issue. A novel
demonstration presented with a functional exploit is eligible for a $60,000
reward.

A bypass report must specifically explain or demonstrate how existing MiraclePtr
protections can be bypassed. A browser UAF 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 the browser process 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 the browser
process, through which the bypass can be clearly and concisely demonstrated
through a POC or exploit, the $100,115 reward amount will be added as a bonus to
the reward amount for the browser 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 $60,000 - in addition to the $100,115 bonus for the
submission of an eligible bypass.

If the demonstration of a bypass, through the submission of an exploit for a
novel MiraclePtr-protected UAF, is submitted before 14 February 2024 as part of
a Chrome browser full chain exploit, the UAF + functional exploit is eligible
for the Full Chain Exploit Bonus. The bypass report / $100,115 bypass reward is
not eligible for the triple or double reward amount through the Full Chain
Exploit Bonus.


V8 SANDBOX BYPASS REWARDS


The V8 Sandbox is a lightweight, in-process sandbox for V8 designed to mitigate
common V8 vulnerabilities. While the sandbox is still under development, it is
covered under a special reward structure with strict and very specific
submission rules. It is expected that submission rules will be relaxed and
evolve as the sandbox matures. Bypasses of the sandbox that meet eligibility
criteria are eligible for a reward of up to $5,000.

Valid submissions must demonstrate the ability to reliably write to a specific
address outside of the V8 sandbox (an arbitrary write primitive) in a d8 binary.
For that, submissions may use the memory corruption API provided by V8 when
compiled with v8_enable_memory_corruption_api = true. The API provides read and
write access to the entire V8 sandbox address space including the V8 heap
region. See the sandbox readme for examples of using this API.

To qualify, a valid submission must write to the "target page," which is
allocated at a random position at process startup. The address of the page is
available in JavaScript as Sandbox.targetPage.

The process to determine whether a submission qualifies is as follows:

 1. A special d8 binary is compiled with the following gn flags:
    
    * is_debug = false
    * dcheck_always_on = false
    * target_cpu = "x64"
    * v8_enable_memory_corruption_api = true

 2. The testcase is executed using this d8 binary and the --sandbox-testing
    flag. When this flag is active, d8 will print the target page to stderr and
    also make it available as Sandbox.targetPage. The testcase may also use
    --expose-gc, but otherwise cannot make use of any additional flags. Note
    also that features specific to d8 (such as the local file access APIs) are
    generally out of scope.

 3. The submitted testcase must result in a write into the target page, in which
    case the program will terminate with a message such as "V8 sandbox violation
    detected!", indicating a successful sandbox bypass. The sandbox bypass must
    be reliable and work at least 50% of the time.

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.


REWARDS FOR V8 BUGS IN STABLE CHANNEL AND OLDER VERSIONS


Until 1 May 2024, 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.


LEGAL POINTS


We are unable to issue rewards to individuals who are on sanctions lists, or who
are in countries (e.g., Cuba, Iran, North Korea, Syria, Crimea, and the
so-called Donetsk People's Republic and Luhansk People's Republic) 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.


SUMMARY CHANGELOG


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

 * 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

 * Privacy
 * Terms
 * About Google
 * Google Products
   
   
 * help Help
   
   
   
 *