Android and Google Devices Security Reward Program Rules
The Android and Google Devices Security Reward program recognizes the contributions of security researchers who invest their time and effort in helping us secure our devices and platforms. Through this program, we provide monetary rewards and public recognition for novel vulnerabilities disclosed to us.
Scope of Program
While we appreciate all vulnerability reports across Google devices, our rewards program specifically focuses on vulnerabilities within the following scope.
This set of devices changes over time, but as of January 16 2025 this covers:
Pixel Families: Pixel 9, Pixel 8, Pixel 7, Pixel 6, Pixel Tablet and Dock, Pixel Watch, Pixel Watch 2 and Pixel Watch 3.
Smart Home and Google Nest:
- Cameras & Doorbells: Nest Cam (battery), Nest Cam (wired), Nest Doorbell (battery), Nest Doorbell (wired)
- Speakers: Nest Mini (2nd gen), Nest Audio
- Displays: Nest Hub Max, Nest Hub (2nd Gen)
- Thermostats: Nest Learning Thermostat, Nest Thermostat
- Nest WiFi, Nest WiFi Pro
- Streaming: Chromecast with Google TV, Chromecast
- Smoke & CO alarm: Nest Protect
- Door lock: Nest x Yale Lock
- Home APIs
Fitbit:
- Trackers: Ace 3, Charge 5,6, Inspire 3, Luxe
- Smartwatches: Ace LTE, Sense 2, Versa 4
This program covers vulnerabilities in eligible devices which are not bugs already covered by other reward programs at Google.
Vulnerabilities in backend components and services are bound to the Google and Alphabet Vulnerability Reward Program (VRP) Rules.
Qualifying Vulnerabilities
Vulnerabilities discovered in the entire product stack, including but not limited to AOSP or other OS code, WearOS, AAOS, OEM code (libraries and drivers), Digital Car Keys, kernel, boot-loader, Secure Element code, TrustZone OS and apps, Find My Device, system on chip (SoC), MicroController Unit (MCU), Boot ROM, RAM memory, Flash memory, filesystem, Trusted Execution Environment (TEE), radio units, etc., are considered eligible if they impact the security of Google’s devices and platforms.
Vulnerabilities in other non-Google-owned code, such as the code that runs in chipset firmware or that supports Digital Car Keys, may be eligible if they impact the security of Google’s devices and platforms.
In general, we reward critical and high severity vulnerabilities. Patches that do not necessarily fix a vulnerability, but provide additional hardening may qualify for Google Patch Rewards.
A few classes of vulnerabilities exist that generally do not qualify for a reward:
- Phishing attacks that involve tricking the user into entering credentials.
- Issues that only affect userdebug builds.
- Bugs that simply cause an app to crash.
- Issues with negligible security impact, as described in Bug Hunter University, with some exceptions.
Qualifying Exploit Chains
We provide an extra reward for a full exploit chain (typically multiple vulnerabilities chained together) that demonstrates arbitrary code execution, data exfiltration, or a lockscreen bypass. A successful exploit chain demonstrates the ability to use a vulnerability (or multiple vulnerabilities) to achieve more than just a crash or an error. For example, to receive a reward for a Code Execution exploit chain, you must demonstrate the ability to execute arbitrary code in the targeted context, bypassing any existing mitigations such as ASLR and CFI. To receive a reward for a Data Exfiltration exploit chain, you must demonstrate that sensitive data (such as user credentials) is extracted from the Titan M chip or other Secure Element, bypassing any existing defenses running on a production device.
The actual reward amount is at the discretion of the reward committee and depends on a number of factors, including (but not limited to):
- Whether there is a buildable exploit.
- Whether there is a detailed write-up describing how the exploit works.
- The initial attack vector (i.e. remote exploitation versus local network versus physical).
- Whether the exploit is device- or build-specific, or whether it works across a broad set of builds and devices.
- The amount of user interaction required for the exploit to work.
- Whether the user could feasibly detect that an exploit is in progress or has completed.
- How reliable the exploit is.
- Exploit chains found on specific developer preview versions of Android are eligible for up to an additional 50% reward bonus.
Maximum exploit rewards for each type of exploit are listed below:
Code execution reward amounts
Description | Maximum Reward |
---|---|
Pixel Titan M with Persistence, Zero click | Up to $1,000,000 |
Pixel Titan M without Persistence, Zero click | Up to $500,000 |
Local App to Pixel Titan M without Persistence | Up to $300,000 |
Secure Element | Up to $250,000 |
Trusted Execution Environment | Up to $250,000 |
Kernel | Up to $250,000 |
Privileged Process | Up to $100,000 |
For the full $1,000,000 reward, the Pixel Titan M exploit must be remote, demonstrate persistence, work on all vulnerable builds and devices, trigger with zero clicks, be easily reproducible with minimal visibility to the user, and have a write-up describing each step of the exploit chain.
See Process types for category descriptions.
Data exfiltration reward amounts
Description | Maximum Reward |
---|---|
High value data secured by Pixel Titan M | Up to $500,000 |
High value data secured by a Secure Element | Up to $250,000 |
Bypass reward amounts
Description | Maximum Reward |
---|---|
Lockscreen bypass [1] | Up to $100,000 |
Device Policy Controller bypass [2] | Up to $75,000 |
[1] This reward is applicable to lockscreen bypass exploits achieved via software that would affect multiple or all devices. Spoofing attacks that use synthetic biometric data (fake masks, fingerprints, etc.) are not eligible for reward.
[2] This reward is applicable to exploits that remove the Device Policy Controller as the admin from a fully managed device.
Report & Reward Guidelines
All bugs should be reported through the Google BugHunter Portal using the vulnerability form.
Patch submissions are eligible for a $1,000 reward and should be attached as a file to the original bug report or shortly after. Patches submitted after a fix has been developed are not eligible for reward.
We ask that you submit high quality reports and include all information necessary to reproduce and assess your report. Reports that do not include all required information may receive a lower reward.
High quality reports for vulnerabilities with a high or critical severity submitted to the Android & Google Devices VRP are eligible for a reward of up to $15,000 (high severity up to $7,000 and critical severity up to $15,000). Moderate severity reports will be eligible for a reward of up to $250 and low severity reports are not eligible for reward. Exploit chains are eligible for a reward up to $1,000,000.
For tips on submitting complete reports, refer to Bug Hunter University.
Report Quality
Reports submitted to the Android and Google Devices VRP are rated as either low, medium, or high quality. Reports that do not demonstrate reachability (a clear explanation showing how the vulnerability is reachable in production code paths, or a POC that uses an API that is callable in production to trigger the issue) will receive a severity rating of NSI (See unreachable bugs).
A high quality report includes:
- An accurate and detailed description of the issue including the device name and version.
- A full root cause analysis describing why the issue is occurring and what Android source code should be patched to fix it.
- A proof-of-concept that effectively, quickly, and easily demonstrates the vulnerability with any applicable reproduction output (e.g., video recording, debugger output, etc.)
- A step-by-step explanation on how to reproduce the vulnerability.
- If applicable, provide fast responses to questions from security testers in no more than one week, and include all requested information.
If the report contains only a WearOS-specific PoC, in addition to the previous requirements, it has to include enough information to prove that the reported issue affects only WearOS-specific code or it’s possible only on WearOS-specific configurations. Google may accept, accept as incomplete, or reject such submissions at our sole discretion if we determine that the report does not meet the above criteria.
Duplicates
A "duplicate" refers to when a vulnerability is submitted that shares the same fix as another issue we were already aware of. This could be due to another researchers submitting a report before yours, us already being aware of it internally, or your report being related to a vulnerability class we are in the process of mitigating. Only the earliest vulnerability report is eligible for reward.
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 buildable proof of concept (against a recent build, no older than 30 days at time of submission), and a patch. In the case of Android, ensure that your Android patch adheres 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. Proofs of concept submitted after an issue has already been assessed, or patches submitted after an issue has already been fixed are generally not eligible for rewards.
Q: What is the difference between an exploit and a vulnerability?
A: A successful exploit chain demonstrates the ability to use a vulnerability (or multiple vulnerabilities) to achieve more than just a crash or an error. For example, to receive a reward for a Code Execution exploit chain, you must demonstrate the ability to execute arbitrary code in the targeted context, bypassing any existing mitigations such as ASLR and CFI. To receive a reward for a Data Exfiltration exploit chain, you must demonstrate that sensitive data (such as user credentials) is extracted from a privileged context, bypassing any existing defenses running on a production device. By contrast, a vulnerability report only needs to show that some sort of security-impacting bug exists, such as an out of bounds read or write, and there is no need to demonstrate that the bug could be turned into full arbitrary code execution.
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. The exact payout amounts are at the discretion of the awards committee, based on the severity of the issue and the completeness of the report.
Q: If the bug is classified as low or moderate severity, when will it be fixed and will a CVE ID be assigned?
A: For vulnerabilities found in Android, Low severity issues are generally addressed in the next major OS release. We generally do not assign CVEs for this severity level.
Q: When will my vulnerability report be addressed?
A: We will make every effort to address security vulnerabilities as quickly as possible and communicate status through the security report. However, please keep in mind that effective and complete remediation requires close collaboration and partnership across our entire ecosystem of device manufacturers.
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 usually do not qualify, but we will evaluate them on a case-by-case basis. Note that we pay out rewards 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: Do I still qualify if I disclose the problem publicly once fixed?
A: Yes, absolutely. We encourage open collaboration. In case of Android vulnerabilities, we also make sure to credit you on the Android Security Acknowledgements page.
Q: I wish to report an issue through a vulnerability broker / someone not Google. 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 typically do 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 in customizations of Android (software originating outside of Google) for eligible devices?
A: No, only bugs in AOSP itself or customizations originating from Google are in scope.
Q: What if a bug has already been reported but still affects the latest software version available for a device currently for sale in the Google Store?
A: We would still request that you submit the report. We are usually only able to reward the first person who reports a bug to us, but will determine that on a case-by-case basis.
Q: For exploit rewards, what is a "remote or proximal" attack vector?
A: A remote attack vector indicates that the bug can be exploited without installing an app or without physical access to a device. This includes bugs that can be triggered by browsing to a web page, reading an email, receiving an SMS message, or connecting to a hostile network. For the purpose of our severity ratings, we also consider "proximal" attack vectors as remote. These include bugs that can be exploited only by an attacker who is physically near the target device, for example, a bug that requires sending malformed Wi-Fi or Bluetooth packets. We consider Ultra-wideband (UWB) and NFC-based attacks as proximal and therefore remote.
Q: For 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, CPUs, SoCs, MCUs, WiFi/Bluetooth/Thread radio units, power management units, etc.). Severity ratings are assigned based on the impact to Android or the device. Only bugs that can manifest themselves or be exploited through the Android device are eligible. We are interested in rewarding any information that enables us to better protect our users. If a third party is impacted, we may contact them directly to share the vulnerability information.
Q: Can you keep my identity confidential from the rest of the world?
A: Yes. If you are the recipient of a reward, we will need your contact details in order to pay you. If a CVE is issued for your vulnerability, you can choose how you would like to be acknowledged, including an option to be acknowledged as "anonymous".
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, patches, and proofs of concept 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 vulnerability form. However, submissions can be sent directly to security(-at-)android(-dot-)com (although submissions through this channel are typically not eligible for reward payouts). Messages sent to this account can be encrypted using the Android Security PGP key.
Legal points
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.
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.