Abuse Vulnerability Reward Program Rules

An "abuse risk" can be defined as a product feature that can cause unexpected damage to a user or platform when leveraged in an unexpected manner. Abuse risks arise when a product doesn't have sufficient guardrails in place to protect its features from being (mis)used in a malicious way.

Contrary to security vulnerabilities, where an identified loophole requires a fix, abuse risks are often inherent to product features. That means that oftentimes, features shouldn't be disabled, but that these product features require protections mitigating their exploitation at scale.

For more details on what constitutes an abuse risk, see our What is an abuse risk? article.

Scope

Any abuse risk in services under the Google VRP scope is in scope for the Abuse VRP.

Qualifying vulnerabilities

Abuse-related vulnerabilities are in scope for this program if the reported attack scenario displays a design or implementation issue in a Google product that could lead to significant harm.

Some examples of abuse-related vulnerabilities:

  • A technique by which an attacker is able to manipulate the rating score of a listing on Google Maps by submitting a sufficiently large volume of fake reviews that go undetected by our abuse systems. In contrast, reporting a specific business with likely fake ratings would not qualify.
  • The ability to import your contacts into a social network app to see which one of your friends is using the app is considered a feature. But, this feature can become an abuse risk if there isn't a quota in place on the amount of contact lookups that can be performed within the app during a given timeframe. Without any restrictions in place, malicious actors could use this feature to build a large database of users for their spam campaigns.

See this additional information detailing how we assess abuse risk reports.

We've also detailed our criteria for bug reports on AI products – see the following section to learn what types of reports are in scope for our program.

Qualifying vulnerabilities in AI products

The following table details our criteria for AI bug reports to assist our bug hunting community in effectively testing the safety and security of our AI products. Our scope aims to facilitate testing for traditional security vulnerabilities as well as risks specific to AI systems. It is important to note that reward amounts are dependent on the impact and the probability of the attack scenario and the type of target affected (for details, see our reward table).

Category Attack Scenario Guidance
Prompt Attacks: Crafting adversarial prompts that allow an adversary to influence the behavior of the model, and hence the output in ways that were not intended by the application Prompt injections that are invisible to victims and change the state of the victim's account or or any of their assets. In Scope
Prompt injections into any tools in which the response is used to make decisions that directly affect victim users. In Scope
Prompt or preamble extraction in which a user is able to extract the initial prompt used to prime the model only when sensitive information is present in the extracted preamble. In Scope
Using a product to generate violative, misleading, or factually incorrect content in your own session: e.g. 'jailbreaks'. This includes 'hallucinations' and factually inaccurate responses. Google's generative AI products already have a dedicated reporting channel for these types of content issues. Out of Scope
Training Data Extraction: Attacks that are able to successfully reconstruct verbatim training examples that contain sensitive information. Also called membership inference. Training data extraction that reconstructs items used in the training data set that leak sensitive, non-public information. In Scope
Extraction that reconstructs nonsensitive/public information. Out of Scope
Manipulating Models: An attacker is able to covertly change the behavior of a model such that they can trigger pre-defined adversarial behaviors. Adversarial output or behavior that an attacker can reliably trigger via specific input in a model owned and operated by Google ("backdoors"). Only in-scope when a model's output is used to change the state of a victim's account or data. In Scope
Attacks in which an attacker manipulates the training data of the model to influence the model’s output in a victim's session according to the attacker’s preference. Only in-scope when a model's output is used to change the state of a victim's account or data. In Scope
Adversarial Perturbation: Inputs that are provided to a model that results in a deterministic, but highly unexpected output from the model. Contexts in which an adversary can reliably trigger a misclassification in a security control that can be abused for malicious use or adversarial gain. In Scope
Contexts in which a model's incorrect output or classification does not pose a compelling attack scenario or feasible path to Google or user harm. Out of Scope
Model Theft / Exfiltration: AI models often include sensitive intellectual property, so we place a high priority on protecting these assets. Exfiltration attacks allow attackers to steal details about a model such as its architecture or weights. Attacks in which the exact architecture or weights of a confidential/proprietary model are extracted. In Scope
Attacks in which the architecture and weights are not extracted precisely, or when they're extracted from a non-confidential model. Out of Scope
If you find a flaw in an AI-powered tool other than what is listed above, you can still submit, provided that it meets the qualifications listed on this page. A bug or behavior that clearly meets our qualifications for a valid security or abuse issue. In Scope
Using an AI product to do something potentially harmful that is already possible with other tools. For example, finding a vulnerability in open source software (already possible using publicly available static analysis tools) and producing the answer to a harmful question when the answer is already available online. Out of Scope
As consistent with our program, issues that we already know about are not eligible for reward. Out of Scope
Potential copyright issues: findings in which products return content appearing to be copyright-protected. Google's generative AI products already have a dedicated reporting channel for these types of content issues. Out of Scope

Non-qualifying vulnerabilities

In addition to the list of non-qualifying vulnerabilities for the Google VRP, please also review the list of AI vulnerabilities above which indicates additional types of non-qualifying vulnerabilities that are out of scope for the Abuse VRP.

Note: Rewards for abuse-related vulnerabilities range from USD $100 to $13,337. The reward amount for these abuse-related bugs depends on the potential probability and impact of the submitted technique.

Impact [1]
High Medium Low
Probability [2] High Up to $13,337 $3,133.7 to $5,000 $1,337
Medium $3,133.7 to $5,000 $1,337 $100 to $500
Low $1,337 $100 to $500 HoF Credit

[1] The impact assessment is based on the attack’s potential for causing privacy violations, financial loss, and other user harm, as well as the size of the user-base at risk.

[2] The probability assessment takes into account any prerequisites to conducting the attack—such as when the attacker needs to guess a victim's ID or needs prior access to the victim's device or account—and the likelihood of the exploitation being discovered by the victim.

The final amount is always chosen at the discretion of the reward panel. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide to pay lower rewards for vulnerabilities that require unusual user interaction; 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

When investigating an abuse-related 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.

Note: Visit our Bug Hunter University articles to learn more about sending good vulnerability reports.

If you have found an abuse-related vulnerability, please submit your report through our standard form (report to Abuse VRP). Please be succinct: your report is triaged by security engineers and a short proof-of-concept link is more valuable than a video explaining the consequences of the concrete case of potential abuse. If necessary, you can use this PGP key.

Note that we are only able to answer abuse-related vulnerability reports. Non-security/abuse bugs and queries about problems with your account should instead be directed to Google Help Centers.

Frequently asked questions

Q: My report has not been resolved within the first week of submission. Why hasn't it been resolved yet?

A: Reports that deal with potential abuse-related vulnerabilities may take longer to assess, because reviewing our current defense mechanisms requires investigating how a real life attack would take place and reviewing the impact and likelihood requires studying the type of motivations and incentives of abusers of the submitted attack scenario against one of our products.

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.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.