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 complete 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 Pixel phones and tablets. This set of devices will change over time, but as of July 2019 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.
In general, we will reward critical, high, and moderate 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:
- Only the first report of a specific vulnerability will be rewarded.
- A bug report must include as much detail as possible, a buildable proof of concept, crash dump if available, and any additional repro steps. For tips on how to submit complete reports, refer to Bug Hunter University.
- Bugs initially disclosed publicly, or to a third-party for purposes other than fixing the bug, will typically not qualify for a reward. Google encourages responsible disclosure, and we believe responsible disclosure is a two-way street; it's our duty to fix serious bugs within a reasonable time frame.
There are also a few classes of vulnerabilities that will generally not qualify for a reward:
- Issues that require complex user interaction. For example, if the vulnerability requires installing an app and then waiting for a user to make an unlikely configuration change.
- Phishing attacks that involve tricking the user into entering credentials.
- Tap-jacking and UI-redressing attacks that involve tricking the user into tapping a UI element.
- Issues that only affect userdebug builds or require debugging access (ADB) to the device.
- Bugs that simply cause an app to crash.
- Low severity issues typically do not qualify for rewards, as described in Bug Hunter University, with some exceptions.
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 complete report includes as much detail as possible, a proof of concept, crash dump if available, and any additional repro steps. 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.
This table shows the reward amounts for typical rewards, effective June 1, 2017. (Any submissions prior to June 1 will be paid using the previous rewards table):
|Severity||Complete Report* + PoC||Payment range (if report includes an exploit leading to Kernel compromise)**||Payment range (if report includes an exploit leading to TEE compromise)**|
|Critical||Required||Up to $150,000||Up to $200,000|
|High||Required||Up to $75,000||Up to $100,000|
|Moderate||Required||Up to $20,000||Up to $35,000|
|Low||Required||Up to $330||Up to $330|
* Bug reports that are incomplete or do not include a proof of concept will receive up to $200 depending on severity.
** Subject to the discretion of the rewards committee
Patch and CTS tests submissions may qualify for a reward up to $1000 each. The final amount will be paid as per the discretion of rewards committee. 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.
Researchers submitting reports including a proof of concept via Android security rewards program for reports originally submitted to third party bug bounty programs may qualify for a $1000 bonus reward, where we do not already have a working proof of concept. To qualify for this bonus reward, researchers are required to provide the CVE ID of the issue having been addressed in an Android Security Bulletin on an eligible device.
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 using the Android Security Issue template. If you are submitting a patch or CTS test, please attach the files to the bug report. 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: Can I still receive a reward even if I don’t submit a full working exploit?
A: Yes! Our program rewards issues that contain a complete report and a working proof of concept, even if a full working exploit is not provided. As reported in our blog, during the most recent full year of our rewards program, our average payout for these categories of issues was over $2000 per issue and $10,000 per researcher in our program. The exact payout amounts will be at the discretion of the awards committee, based on the severity of the issue and the completeness of the report.
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: If the bug is classified as low, when will it be fixed and will a CVE ID be assigned ?
A:Low severity issues are generally addressed in the next major versions, instead of through our Monthly Security Bulletins, and we will generally not assign CVEs for this severity level.
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?
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 would still request that you submit the report. We are likely only be able to reward the first person who reports a bug to us, but will determine that on a case by case basis.
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, or receiving an SMS/MMS message. 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.
Q: Can I submit my report without having to create a Google account?
A: We would strongly prefer that report submissions take place through the Android Security issue template. However, submissions can be sent directly to security(-at-)android(-dot-)com (although submissions through this channel are typically not eligible for rewards payouts). Messages sent to this account can be encrypted using the Android Security PGP key.
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.