Google Mobile Vulnerability Reward Program Rules
Google’s Mobile Vulnerability Rewards Program (Mobile VRP) focuses on first-party Android applications developed or maintained by Google.
The Mobile VRP recognizes the contributions and hard work of researchers who help Google improve the security posture of our first-party Android applications.
The goal of the program is to mitigate vulnerabilities in first-party Android applications, and thus keep users and their data safe.
Tip: New to Android app research and hacking, and looking for learning resources to get started on your journey? See our dedicated Android learning page for inspiration.
Program scope
Only apps published by the developers in the list below or apps in the Tier 1 list (see Application tiers) are in scope for the Mobile VRP:
- Google LLC
- Developed with Google
- Research at Google
- Red Hot Labs
- Google Samples
- Fitbit LLC
- Nest Labs Inc.
- Waymo LLC
- Waze
We also encourage you to check out our other related programs:
- Android and Google Devices Security Reward Program which offers rewards for vulnerabilities in Android Open Source Project
- Chrome Vulnerability Reward Program which offers rewards for vulnerabilities in Chrome
Qualifying vulnerabilities
Arbitrary code execution (ACE)
Vulnerabilities of this type allow an attacker to execute arbitrary code in the context of the vulnerable application.
In order to qualify, the ACE should allow an attacker to run native code of their choosing on a user’s device without user knowledge or permission, in the same process as the affected app (there is no requirement that the OS sandbox needs to be bypassed).
Examples include:
- Attacker gaining full control of the application, meaning code can be downloaded from the network and executed
- Overwriting a
.so
file with a malicious.so
file that is executed by the victim app - Executing Java code in order to call exec and thus run arbitrary native code
Tricking a user into installing an app and executing code within that app itself does not qualify.
Theft of sensitive data
This category includes vulnerabilities that lead to unauthorized access to sensitive data from an app on an Android device.
For the scope of this program, sensitive data is classified as:
High Impact Data
- Data that enables unauthorized access to a user’s account (e.g. login credentials, or authentication tokens that are able to perform sensitive state-changing actions that result in non-trivial damage to the victim, government IDs, medical or payment information).
Low Impact Data
- Sensitive user-generated data: contact list information, photos (unless made public by default), content of a user’s messages (email, instant messages, text messages), call/SMS logs, web history (being able to profile or enumerate a specific user based on their web history), or browser bookmarks.
- Information that is linked or linkable to an individual, such as educational, and employment information.
Location information alone does not qualify (unless combined with the ability to uniquely identify an individual).
Access to non-sensitive internal files of another app also does not qualify.
Examples of vulnerabilities that impact sensitive data include, but are not limited to:
- Insecurely stored data files containing sensitive data that are accessible to other apps
- Sensitive data sent over insecure network connections that can be intercepted
- Insecurely designed app internals like content providers or activities that can be manipulated to expose sensitive data
Additional vulnerability types in scope
Vulnerabilities of this type are not strictly within scope, but will be taken into consideration if they are shown to have a security impact. Typically, these are security weaknesses that need to be used in conjunction with other vulnerabilities to create an exploit chain.
Examples of vulnerabilities which in themselves might not result in direct ACE or the theft of sensitive data, but could still qualify for a reward are:
- Path traversal / zip path traversal vulnerabilities leading to arbitrary file write
- Intent redirections leading to launching non-exported application components
- Vulnerabilities caused by unsafe usage of pending intents
- Orphaned permissions
Non-qualifying issues
Some examples of issues that do not qualify for a reward are:
- Certain common low-risk vulnerabilities deemed trivially exploitable. A few such issues are described here.
- Vulnerabilities that allow access to non-sensitive media in external storage
- Variants of Strandhogg and Tapjacking
- Vulnerabilities that do not work on the latest available operating system version
- Hardcoded API keys
- Attacks that require a rooted device
- Secondary lockscreen bypasses
In addition to the non-qualifying issues listed above, attack scenarios that require an unreasonable amount of user interaction or social engineering will be considered out of scope.
For more information on vulnerability classes, please see this PDF.
Application tiers
The Mobile VRP distinguishes three application tiers. Application tiers map to reward tiers and determine the final payout decision together with the vulnerability type and exploitation scenario as described in Reward amounts.
The final decision on which category an application falls into is taken by the Mobile VRP panel.
Tier 1
Tier 1 applications are limited to the applications listed here:
Name | Package name |
---|---|
Google Play Services | com.google.android.gms |
AGSA | com.google.android.googlequicksearchbox |
Google Cloud | com.google.android.apps.cloudconsole |
Gmail | com.google.android.gm |
Tier 2
Most applications that interact in some way with either a Tier 1 application, user data, or Google's services fall into the tier 2 category.
Tier 3
Most applications which do not handle user data or interact with Google’s services fall into the tier 3 category.
Reward amounts
The following tables show the maximum reward amounts available for each of the three application tiers distinguished by the Mobile VRP. Within each tier, maximum reward amounts depend on the vulnerability type and the scenario in which the given vulnerability can be exploited.
PS! The rewards listed in the following tables are for GOOD QUALITY reports. See Report Quality for more information on how we measure the quality of reports, and how that influences reward amounts.
Application tier 1 rewards
Category | 1) Remote/No User Interaction | 2) User must follow a link that exploits the vulnerable app | 3) User must install malicious app or victim app is configured in a non-default way | 4) Attacker must be on the same network (e.g. MiTM) |
---|---|---|---|---|
A) Arbitrary Code Execution | $300,000 | $150,000 | $15,000 | $9,000 |
B) Theft of Sensitive Data* | $75,000 | $37,500 | $9,000 | $6,000 |
C) Other Vulnerabilities | $24,000 | $9,000 | $4,500 | $2,400 |
Application tier 2 rewards
Category | 1) Remote/No User Interaction | 2) User must follow a link that exploits the vulnerable app | 3) User must install malicious app or victim app is configured in a non-default way | 4) Attacker must be on the same network (e.g. MiTM) |
---|---|---|---|---|
A) Arbitrary Code Execution | $150,000 | $75,000 | $7,500 | $4,500 |
B) Theft of Sensitive Data* | $37,500 | $18,750 | $4,500 | $3,000 |
C) Other Vulnerabilities | $12,000 | $4,500 | $2,250 | $1,200 |
Application tier 3 rewards
Category | 1) Remote/No User Interaction | 2) User must follow a link that exploits the vulnerable app | 3) User must install malicious app or victim app is configured in a non-default way | 4) Attacker must be on the same network (e.g. MiTM) |
---|---|---|---|---|
A) Arbitrary Code Execution | $45,000 | $22,500 | $2,250 | $1,350 |
B) Theft of Sensitive Data* | $11,250 | $5,625 | $1,350 | $900 |
C) Other Vulnerabilities | $3,600 | $1,350 | $675 | $360 |
* Rewards are calculated with the HIGHEST impact for Theft of Sensitive Data.
Report Quality
Rewards are adjusted based on the quality of the report. The main factors considered are:
- Demonstrated security impact of the reported vulnerability – Impact is judged based on the actual reported impact of the vulnerability, and not on a potential impact of the vulnerability. An example of this would be a vulnerability that allows for arbitrary file write. In some cases this could lead to ACE, however, if you do not demonstrate this in your report, the reward amount will not reflect this.
- Overall report quality – See the following sections for details.
Exceptional Quality (1.5x reward amount)
An Exceptional Quality report has several of the following characteristics (in addition to the characteristics of a Good Quality report described below):
- Includes a proposed patch or effective mitigation to the vulnerability
- Includes a root cause analysis, which helps us find other similar variants of the issue
Good Quality (1x reward amount)
A Good Quality report has several of the following characteristics:
- An accurate and detailed description of the issue including the device name and version, any relevant version numbers for applications and OS
- A proof-of-concept that effectively, quickly, and easily demonstrates the vulnerability with any applicable reproduction output (e.g., video recording, APK file, etc.)
- An example application in the form of an APK, in cases that the vulnerability can be fully triggered by using ADB, that is also acceptable
- A step-by-step explanation on how to reliably reproduce the vulnerability
- A clear analysis and demonstration of the impact of the vulnerability
In addition to the characteristics listed above, we also expect the researcher to be responsive when asked questions and accurately answer any queries about the vulnerability.
Low Quality (0.5x reward amount)
Reports which do not meet the criteria to qualify as Good Quality reports.
Rewards – Additional information
The panel can apply a discretionary $1,000 bonus – e.g. for a particularly surprising or novel use of a vulnerability type, vulnerabilities in an SDK or an exceptional writeup.
Note that the values indicated in the above tables are maximum values, the exact value is always determined at the discretion of the reward panel.
Reporting bugs
When investigating a vulnerability, please only ever target your own accounts. 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.
Tip! Visit our Bug Hunter University articles to learn more about sending good vulnerability reports.
If you have found a security vulnerability, please submit your report through the form available on our report page.
For vulnerabilities regarding Google Chrome on Android and Chrome Remote Desktop, please refer to the Chrome Vulnerability Reward Program.
Please be succinct: Your report is triaged by security engineers and a short proof-of-concept is more valuable than a video explaining the consequences of a specific bug. If necessary, you can use this PGP key to encrypt your communications with us.
Note that we are only able to answer technical vulnerability reports. Non-security bugs and queries about problems with your account should instead be directed to Google Help Centers.
Duplicates
A “duplicate” refers to when a vulnerability report is submitted that is very similar or identical to a previously submitted report.
When duplicates occur, only the first report that was received is awarded (provided that it can be fully reproduced).
Third-party vulnerabilities and SDK or library vulnerabilities
- If you have identified a vulnerability in a third-party mobile application, please refer to the Google Play Security Reward Program.
- If you have identified a vulnerability in an SDK or library used by a first-party Google app (but not developed by Google), please submit it directly to the maintainer of the affected SDK or library. If this is not possible you can submit it to Mobile VRP.
- If multiple reports of the same SDK or library vulnerability are received, even across different apps, they will be considered duplicates of the earliest report submission due to having the same root cause.
- Vulnerabilities found in AOSP should be reported to Android and Google Devices Security Reward Program
FAQ
Q: If I find a valid (ACE/Theft of sensitive data) vulnerability in Chrome on Android, should I submit it to Chrome VRP or Mobile VRP?
A: Researchers should submit Chrome vulnerabilities on Android to the Chrome Vulnerability Reward Program using the report form (report to Chrome VRP).
Q: If I discover a vulnerability in the Gmail Android app, can it be considered for rewards from multiple VRP programs?
A: Researchers should submit vulnerabilities in apps (such as the Gmail Android App) to the Mobile VRP. That said, bugs may still be eligible for a bonus from multiple programs. If this is the case, this will be handled internally; bug hunters do not need to submit reports to several programs.
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 the program 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 software covered by this program.