Google Play Security Reward Program (GPSRP) is a bug bounty program offered by Google Play, in collaboration with HackerOne and the developers of certain popular Android apps. It recognizes the contributions of security researchers who invest their time and effort in helping make apps on Google Play more secure.

The goal of the program is to identify and mitigate vulnerabilities in participating apps on Google Play, and keep Android users, developers and the Google Play ecosystem safe.

Developers of Android apps are invited __to join the program to help incentivize security research through the bug bounty model.

Table of Contents

i. How Does it Work?
ii. Program Rules
iii. Vulnerability Criteria & Rewards
iv. Scope
v. Legal Points

How does it work?

At a high level :

• Developers of Android apps apply __to join the program. Google and HackerOne review and determine eligibility to participate, then the apps are added to the scope of this program.
• Hacker identifies vulnerability in an in-scope app and reports it directly to the app’s developer via their current vulnerability disclosure process.
• App developer works with the hacker to resolve the vulnerability.
• Once the vulnerability has been resolved, the hacker can request a payout from the Google Play Security Reward Program. This in addition to the bounty that the app developer may independently offer.

Program Rules

• All vulnerabilities must always be reported directly to the app developer first. This program is only for requesting bonus bounties after the original vulnerability was resolved with the app developer. Only issues that have been patched within the last 90 days will qualify.
• Only developers who have expressed a commitment to fixing bugs which are disclosed to them have been invited to the program. It is the responsibility of each developer to respond and fix bugs in a timely manner.
• All reports are subject to HackerOne's disclosure guidelines __.
• Reports must contain the information requested in the submit report form. Reports not containing the required information and not meeting the criteria for this program will not be eligible for a reward.
• When duplicates occur, only the first report that was received is awarded (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue reported to same developer (or multiple developers in some cases) will be awarded one reward.
• We aim to be fair; any and all reward decisions under the Google Play Security Rewards Program are ultimately at the discretion of Google and HackerOne. App developers have no control over the Google Play Security Rewards Program administered by HackerOne.
• Bounty amounts mentioned are only representative and may be upgraded or downgraded by the decision makers.
• Some Alphabet branded services hosted in less common domains operated by vendors or partners are out of scope. In addition, Google VRP (not GPSRP) policies __apply when deciding the eligibility of vulnerability reports pertaining to Google developed apps. If in doubt, talk to us first. To allow time for internal review and remediation, apps pertaining to companies acquired by Google are subject to a six-month blackout period. Bugs reported sooner than that will typically not qualify for a reward.

Vulnerability Criteria & Rewards

At this time, the following vulnerabilities qualify for the Google Play Security Reward Program. This list may be expanded in the future to cover more issues.

1) RCE (Remote Code Execution) - $20,000

RCE (Remote Code Execution) vulnerabilities and corresponding POCs (Proof of Concepts) qualify for a $20,000 reward. The RCE vulnerability should allow an attacker to run native ARM code of their choosing on a user’s device without user knowledge or permission.

Examples may include:

• Attacker gaining full control, meaning code can be downloaded from the network and executed (download and execute arbitrary native ARM code in the same process as the affected app)

Please note, executing arbitrary JavaScript does not qualify for the RCE category.

2) Theft of insecure private data - $3,000

Vulnerabilities and corresponding POCs (Proof of concepts) that lead to theft of private data qualify for a $3,000 reward, based on the following criteria:

• Vulnerabilities that lead to unauthorized access to personally identifiable information in a way that an attacker can steal them from Android devices with default security settings (e.g. non-rooted).
  • For the scope of this program, personally identifiable information is classified as: login credentials, authentication tokens, names, contact list information, photos and other files from SD card, content of a user email, call log, SMS log, web history, browser bookmarks, and info from private/data/directories of other apps. Please note, location or GPS coordinates alone do not qualify as personally identifiable information.
  • Examples of this include, but are not limited to:
  • Insecurely stored data files that are accessible to other apps
  • 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 data
• Vulnerabilities that result in the ability to easily phish a user without user interaction, e.g. causing a WebView or other interface to become visible to the user without any user interaction, running in the same process as the affected app, and that appears to be within the same interface as the victim app.

Additionally, vulnerabilities that result in unauthorized, irrecoverable destruction of sensitive user data listed above may also qualify (e.g. deleting a user’s account, irrecoverable destruction of data, etc.).

Note: To qualify for a reward, the data theft must occur either through MITM of the network or a hostile app installed on the same device. If a hardcoded key or secret is found within the app that provides access to sensitive data types listed above, this may also count.

3) Access to protected app components - $3,000

Vulnerabilities and corresponding PoCs (Proof of Concepts) where an app component processes a passed Intent (e.g. from startActivity, sendBroadcast, startService, or bindService) from another app without properly validating the Intent, resulting in the target app performing an operation that the sending app doesn't have permission to do qualify for a $3,000 reward. The operation in question needs to be security-relevant (e.g. changing sharing settings to provide an attacker unauthorized access to sensitive data, publishing/editing something on behalf of the user without their consent which exposes sensitive data, changing security settings in a way that makes it easier to compromise the user's data or functionality, changing or providing unauthorized access to credentials, etc).

• Examples of this behavior include, but are not limited to:
  • Allowing an app to send an SMS message if it doesn't have the SEND_SMS permission
  • Bypass a protection (e.g. login form) by directly calling an Activity
  • Manipulating intents to steal auth tokens or run scripts in a web origin not under your control
• Examples of issues that would not qualify include:
  • Making a GET/POST request, without being able to fool the vulnerable app into doing something dangerous with the returned HTTP payload (e.g. Android APIs are often used for actions like playing a media file by URL)

4) Local code execution - $4,000

Vulnerabilities and corresponding PoCs (Proof of Concepts) where an app processes malicious input from another application on the same device, resulting in code execution on the device (e.g. ARM, Java) will qualify for a $4,000 reward. For example:

• An app loading and executing arbitrary Java code from a file specified on local storage, where an attacker can combine a file overwrite vulnerability to place Java code of their choosing in a place on the filesystem where the victim app will load and run it

For more information on vulnerability classes, please see this PDF: {F681840}

A note on SDK and library vulnerabilities - if you have identified a vulnerability in an SDK or library used by an app developer (but not maintained by the app developer), please submit it directly to the maintainer of the affected software. If this is not possible and you leverage HackerOne’s Disclosure Assistance as described in the Scope section to submit a report on a vulnerable app due to an SDK or library they are using, please note that SDK and library vulnerabilities will only receive a single payout at 2x the normal reward amount (e.g. a $3k issue would be worth $6k) to reflect the additional impact of these types of bugs. 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.

Non-qualifying issues

• Certain common low-risk vulnerabilities deemed trivially exploitable will not qualify for rewards. A few such issues may be found here __. Most common examples include vulnerabilities that result from an uninformed OAuth grant (by the user) to a 3rd party app, or phishing attacks (solely) based on user deception.
• Attacks requiring physical access to devices.
• MITM attacks over insecure connections (not including sensitive data sent over HTTP).
• Intent or URL Redirection leading to phishing.

Known issues

Issues already known to Google (and in the process of being mitigated/fixed) that can be used to uncover similar vulnerabilities across multiple apps in Google Play Store will be published to the Known issues list. Such vulnerabilities are not deemed severe enough to warrant the default reward from Google Play (while still being relevant for the developer to fix - and pay, where applicable), but may qualify for a smaller bounty (listed below).

Specifically, passing malicious URL input to an app resulting in the app processing a symlink that results in access to sensitive data.
Specifically, passing malicious URL input to an app resulting in the app processing a javascript: style URL resulting in access to sensitive data.
Specifically, passing malicious URL input to an app resulting in the app processing a file: style URL resulting in access to sensitive data.
**For example, passing malicious URL input to an app that results in the user navigating to an attacker-controlled website, where the app automatically appends cookies or parameter values containing session information to the requests.

Additional criteria

There is no requirement that OS sandbox needs to be bypassed.

Scope

Only Google developed applications and those developed by participating developers (in the list below) are in scope to be considered for a bounty. Only vulnerabilities that work on Android 5.0 devices and higher will qualify.

• For Google-developed Android apps : Please report vulnerabilities through the Google Vulnerability Reward Program __or, for Chrome specifically, to the Chrome Reward Program. You can submit a reward claim here after the vulnerability is fixed.
• For rest of the apps : All vulnerabilities must be reported directly to the app developer first through the listed channel. Only submit issues to the Play Security Rewards Program that have already been resolved by the developer. Additionally, only issues that have been patched within the last 90 days will qualify for a reward from Google Play. If you wait longer than 90 days from a fix being made publicly available, your report will not qualify!

Hackers - if you have general feedback based on your experience with GPSRP and participating app developers, please submit it here __. If you need assistance with a specific app developer, please submit a GPSRP mediation request __.

App developers - if you feel you are in the incorrect tier, please contact gpsrp[@]google.com. These average stats are updated periodically based on publicly accessible metrics.

Tier 1

Tier 1 programs have average first response times of < 1 day, and resolution times of <= 1 month.

Tier 2

Tier 2 programs have average first response times of <= 1 day, and/or triage times of <= 5 days, and/or resolution times of <= 3 months.

Tier 3

Tier 3 programs either do not meet the criteria for tier 2 or above, or do not publicly display metrics around time to first response, time to triage, or time to resolution.

Over time, additional apps may come into scope, so please check back regularly.

For Finders who participate in certain programs of particular customers, to the extent described in the Program Policies, HackerOne may share contact information about those Finders (name, company name (if applicable) and email address) to allow those Customers to contact those Finders to allow them to interact directly.

If you believe you’ve identified a vulnerability in a Play app not listed in scope, please disclose the vulnerability directly to the app developer. If the app developer is unresponsive or does not have a means of receiving vulnerability reports, and the app has over 100 million installs (as indicated on the Google Play Store), you may attempt to disclose the issue to the app developer by submitting the vulnerability to this program under the “App on Play with >= 100 million installs, not listed in scope” asset. Please review the terms listed in the asset’s description before submitting your report. Google makes no guarantees in terms of the ability of HackerOne or Google to successfully disclose the issue to the affected app developer. If the issue qualifies based on the criteria listed in this policy, it may be eligible for a reward.

If an app developer has a publicly facing vulnerability disclosure or bug bounty program, you can submit a reward claim to this program (as you would for the apps specifically listed in scope) as long as the developer has already confirmed that the vulnerability has been fixed in the last 90 days. The application must have over 100 million installs (as indicated on the Google Play store).

Google will reach out to the affected app developer to confirm your claim and determine if the report is eligible for a reward based on the current vulnerability criteria. If the app developer has a private program, please ask the app developer for permission before submitting a reward claim here.

Legal Points

We are unable to issue rewards to individuals who are on US sanctions lists, or who are in countries subject to US sanctions. 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 reward 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.

Thank you for helping improve the security of the Google Play ecosystem!

Pending Policy Update - effective March 11, 2020

The following sections outline updates to the policy that will replace the above policy, and will come into effect for any reports submitted on or after March 11, 2020. Note the following sections do not include the scope section or introductory paragraphs, but that content will largely remain the same. This update is being added to the policy two weeks earlier than its effective date to help provide advance notice of these upcoming changes.

Hacker “Cheat Sheet”

GPSRP focuses on identifying vulnerabilities in popular Android apps on Google Play (i.e. with 100 million or more installs, and any apps listed in scope). Please see the rules and reward criteria below for more detail.

Disclosure Process

• To Developer: If an organization has their own public means of receiving vulnerability reports (security@ email address and associated disclosure policy, or a public vulnerability disclosure or bug bounty program), always submit the vulnerability to them first. After the vulnerability is fixed (or if 30 days have passed with no response), you can submit the vulnerability details to GPSRP.

• To GPSRP: If an organization has no obvious public means of receiving vulnerability reports and the app has 100 million or more installs, you may attempt to disclose the issue to the app developer by submitting the vulnerability directly to GPSRP.
  Please review the terms before submitting your report. Google makes no guarantees in terms of our ability to successfully disclose the issue to the affected app developer. If the issue qualifies based on the criteria listed in this policy, it may be eligible for a reward.

Duplicates

A “duplicate” refers to when a vulnerability report is submitted that is very similar or exactly the same as a previously submitted report.

• When duplicates occur, only the first report that was received is awarded (provided that it can be fully reproduced).
• Very similar issues in one or more apps by the same developer may be considered as duplicates of the first report submitted (e.g. a vulnerability with a single root cause present in multiple activities).

SDK and library vulnerabilities

• If you have identified a vulnerability in an SDK or library used by an app developer (but not developed by the app developer), please submit it directly to the maintainer of the affected SDK or library. If this is not possible and you submit a report on a vulnerable app due to an SDK or library they are using, please note that SDK and library vulnerabilities will only receive a single payout at 2x the normal reward amount (e.g. a $3k issue would be worth $6k) to reflect the additional impact of these types of bugs.
• 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.
• The SDK or library must be in use by multiple organizations. Code that is shared across multiple apps by the same parent organization will not be eligible for the SDK/library bonus.

Program Rules

• If you are submitting a bonus reward claim for a fixed issue you’ve reported to an app developer, only issues that have been patched within 90 days of report submission to GPSRP will qualify.
• Reports must contain the information requested in the submission form. Reports not containing the required information and not meeting the criteria for this program will not be eligible for a reward.
• When duplicates occur, only the first report that was received is awarded (provided that it can be fully reproduced). Please see the hacker cheat sheet for more info on how duplicates are handled.
• We aim to be fair; any and all reward decisions under the Google Play Security Reward Program are ultimately at the discretion of Google. App developers have no control over the Google Play Security Reward Program.
• Any vulnerabilities identified in first party apps should be submitted to the Google VRP __, and are subject to the Google VRP program rules __.

Reward Criteria

Rewards are based on impact and exploitability. The following table outlines the usual rewards chosen for the most common classes of bugs.

| 1) Remote / no user interaction | 2) User must follow a link, vulnerable app must be already installed | 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)
---|---|---|---|---
Arbitrary code execution | $20,000 | $10,000 | $4,000 | $1,000
Theft of sensitive data | $5,000 | $3,000 | $1,000 | $500

The following sections outline the impacts above in more detail.

Arbitrary Code Execution (ACE)

In order to qualify, ACE should allow an attacker to run native ARM 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 may include:

• Attacker gaining full control, 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 ARM code

Executing arbitrary JavaScript does not qualify. Tricking a user into installing an app and executing code within that app itself does not qualify.

Theft of sensitive data

This impact 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:

• Data that results in unauthorized access to a user’s account (e.g. login credentials, authentication tokens)
• Sensitive user generated data: contact list information, photos, content of a user’s messages (email, instant messages, text messages), call log, SMS log, web history, browser bookmarks, and other sensitive info from private/data/directories of other apps.

Location information alone does not qualify (unless combined with the ability to uniquely identify an individual by name).

Access to non-sensitive internal files of another app does not qualify.

Examples of vulnerabilities that result in this impact 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

For more information on vulnerability classes, please see this PDF: {F681840}

Non-qualifying issues

• Certain common low-risk vulnerabilities deemed trivially exploitable will not qualify for rewards. A few such issues may be found here.
• Attacks requiring physical access to devices, including physical proximity for Bluetooth.
• Destruction of sensitive data.
• Tricking a user into installing a malicious app without READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permissions that abuses a victim app to gain those permissions. Intent or URL Redirection leading to phishing.

Known issues

Issues already known to Google (and in the process of being mitigated/fixed) that can be used to uncover similar vulnerabilities across multiple apps in Google Play Store will be published to the known issues list. Such vulnerabilities are not deemed severe enough to warrant the default reward from Google Play (while still being relevant for the developer to fix), but may still qualify for a smaller reward (listed below).

Legal Points

We are unable to issue rewards to individuals who are on US sanctions lists, or who are in countries subject to US sanctions. 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 reward 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.

For Finders who participate in certain programs of particular customers, to the extent described in the Program Policies, Google may share contact information about those hackers Finders (name, company name (if applicable) and email address) with app developers to verify the hacker was the original reporter of an issue, and to allow those app developers to contact those Finders to allow them to interact directly. For any reward claim on a fixed vulnerability, Google will reach out to the affected app developer to confirm your claim and determine if the report is eligible for a reward based on the current vulnerability criteria. If the app developer has a private program, please ask the app developer for permission before submitting a reward claim here.

Thank you for helping improve the security of the Google Play ecosystem!