Android Security Rewards Program Rules

The Android Security Rewards program recognizes the contributions of security researchers who invest their time and effort in helping us make Android more secure. Through this program we provide monetary rewards and public recognition for vulnerabilities disclosed to the Android Security Team. The reward level is based on the bug severity and increases for higher quality reports that include reproduction code, test cases, and patches.

Scope of program

This program covers security vulnerabilities discovered in the latest available Android versions for Nexus phones and tablets (including the latest Android N developer preview or beta builds) currently available for sale in the Google Store in the U.S. This set of devices will change over time, but as of May 2016 this covers:

Android Security Rewards covers bugs in code that runs on eligible devices and isn't already covered by other reward programs at Google. Eligible bugs include those in AOSP code, OEM code (libraries and drivers), the kernel, and the TrustZone OS and modules. Vulnerabilities in other non-Android code, such as the code that runs in chipset firmware, may be eligible if they impact the security of the Android OS.

Non-AOSP apps developed by Google and published in Google Play may be covered under our Google VRP, which also covers server-side issues. Vulnerabilities in Chrome may be handled under the Chrome Rewards program.

At this time, vulnerabilities that only affect other Google devices (such as Nexus Player, Android Wear, or Project Tango) are not eligible for Android Security Rewards.

Qualifying vulnerabilities

In general, we will reward critical, high, and moderate severity vulnerabilities. We may in special cases consider offering rewards for test cases and patches for low-severity vulnerabilities. Patches that don't necessarily fix a vulnerability but provide additional hardening may qualify for Google Patch Rewards.

There are a few rules that we follow when rewarding a vulnerability report:

There are also a few classes of vulnerabilities that will generally not qualify for a reward:

Reward amounts

The reward amount depends on the severity of the vulnerability and the quality of the report. A valid but low quality bug report may receive up to $200. A good bug report includes as much detail as possible, a proof of concept, crash dump if available, and any additional repro steps. A good bug report with a proof of concept may receive up to $4,000. Bug reports that include a proof of concept, CTS test, and patch may receive up to $8,000. The proof of concept should be standalone reproduction code or a malformed file that reproduces the issue. Malformed files that are copyright material or can’t be distributed with a CTS test may qualify for a lower reward amount.

Submitted CTS tests and patches must apply cleanly to AOSP's master branch, comply with Coding Style Guidelines, and be accepted as the actual fix to be eligible for these additional reward amounts.

This table shows the reward amounts for typical rewards, effective June 1, 2016. (Any submissions prior to June 1 will be paid using the previous rewards table):

Severity Bug Report* + Proof of concept + CTS + patch Bug Report* + Proof of concept + (CTS or patch) Bug Report* + Proof of concept
Critical $8,000 $6,000 $4,000
High $4,000 $3,000 $2,000
Moderate $2,000 $1,500 $1,000
Low $1,000 $500 $333

* Bug reports that are incomplete or do not include a proof of concept will receive up to $200 depending on severity.

Besides these reward levels, we offer additional rewards for functional exploits:

The final amount is always chosen at the discretion of the reward panel. In particular, we may decide to pay even more 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 to AOSP's public bug tracker using the Security Bug Report template. If you are submitting a patch or CTS test, please attach the patches to the bug report instead of uploading them directly to AOSP. Again, if your patch or test doesn’t conform to Android's Coding Style Guidelines, we may reduce the reward amount.

When investigating a vulnerability, please, only ever target your own devices. 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.

Frequently asked questions

Q: How can I maximize the potential reward for my report?

A: To earn as much money as possible for your bug, include a high quality bug report, a proof of concept, a patch, and a CTS test. Ensure that your patch and CTS test adhere to Android's Code Style Guidelines; we may lower the reward amount if the code requires a lot of fixing up before we can include it in the Android source tree.

Q: How do I find out if my bug is eligible?

A: We'll let you know if your bug may be eligible, and we'll let you know once the panel decides on a reward amount. We can't tell you if your bug will qualify before you give us the details.

Q: What happens if I disclose the bug publicly before a fix is available?

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.Note that we will pay rewards out before the bug has been fixed in many cases. If you disclose the bug after getting the reward but without giving us a reasonable deadline for fixing the issue, you may not be eligible for future rewards.

Q: What do you consider a reasonable disclosure deadline?

A: Google's own Project Zero gives us a 90 day disclosure deadline when they report Android bugs. We think that's reasonable.

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 Android Security Acknowledgements page.

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 that are only present in other popular, non-Nexus devices?

A: If a bug does not affect the latest version of Android available on an eligible device currently for sale in the U.S. in the Google Store, it will not qualify for a reward.

Q: What about bugs in custom ROMs for eligible Nexus devices?

A: No, bugs in custom ROMS are not covered.

Q: What if a bug has already been reported but still affects the latest Android version available on a device currently for sale in the Google Store?

A: We'll only reward the first person who reports a bug to us.

Q: For the purpose of exploit rewards, what is a "remote or proximal" attack vector?

A: A remote attack vector means that the exploit could be launched against a target without regard for the device's physical location. For example, the exploit could be triggered by visiting a web page, by opening an email, receiving an SMS message, or connecting to a hostile network. Proximal means that the exploit must be launched in close physical proximity to the device. For example, an attack involving a bug in the WiFi, radio, or Bluetooth stacks require being physically proximal to the target device.

We consider attacks against NFC and USB to be a physical attack vector and exploits are rewarded the same as if the exploit was launched from an app.

Q: For the purpose of exploit rewards, what is a "kernel compromise"?

A: We mean that the integrity of the kernel has been breached. This could be achieved with arbitrary code execution in the kernel or with arbitrary kernel writes — for example, to disable SELinux.

Q: What about bugs in third-party components?

A: These bugs are often eligible (e.g., image libraries, media libraries, compression libraries, etc.). Note that we assign the severity rating based on the impact to Android. Only bugs that can be manifest or exploited through Android will be eligible.

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 patch and 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: When submitting a bug, please include steps to reproduce the issue and a working proof of concept to maximize your reward. We are willing to accept a fully working exploit a few weeks after the initial report. Exploits submitted outside of this time frame are unlikely to be rewarded.

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Crimea, 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.

To avoid potential conflicts of interest, we will not grant rewards to people employed by Google or Google Partner companies who develop code for devices covered by this program.