Google reportedly pauses a category of its vulnerability rewards program; key details remain unconfirmed

The reported measure affects part of the program, not necessarily the entire system

Available information describes a pause in the acceptance of certain reports through Google’s Open Source Software Vulnerability Reward Program, known as the OSS VRP. The reported scope is narrower than a general suspension: it concerns product vulnerabilities, while reports related to the software supply chain are said to be outside the pause. That distinction appears in the available coverage, but the material here does not include a Google notice detailing the affected categories.

It would therefore be premature to summarize the change as the program closing or to claim that Google has stopped accepting every type of finding. The supplied information also does not confirm when the pause began, when it will be reviewed, or whether there is a timetable for reopening submissions. The existence of a rewards program, or of Google initiatives related to AI security, does not settle those questions. They are separate matters and require specific confirmation.

For anyone considering reporting a vulnerability, the most useful practical step is to check the current rules for the relevant category before preparing a submission. Based on the documentation provided, it is not possible to establish whether the pause is still in effect, how it is applied on the submission platform, or what alternatives are available in the meantime.

The explanation linking the pause to AI remains incomplete

The reported pause has been linked to an increase in invalid reports associated with artificial intelligence tools. However, the official Google material supplied about the company’s security strategy confirms the announcement of a rewards program related to AI vulnerabilities, not the pause to the OSS VRP. The available material does not explain that decision, provide data on rejected reports, or establish a causal link to generative models.

That distinction matters. The fact that some reports were prepared with AI assistance does not show that the tool caused an error, that the report was invalid, or that every use of AI produces useless results. Establishing a causal relationship would require, at minimum, clear criteria for identifying the use of these tools and comparable data on the validity of submissions. Neither those figures nor a methodology has been supplied.

It is also unclear exactly what “AI-generated” means in this context. It might refer to text drafted by a model, a hypothesis suggested during an investigation, or an automated analysis of code. These are different uses and do not carry the same evidentiary weight. Without a published definition that applies to the program, the label should not be treated as a general rule about report quality.

There are no verified figures to measure the problem

The available public explanation points to a review burden caused by reports that do not describe valid or exploitable vulnerabilities. But the supplied sources do not provide a submission total, rejection rate, comparison with earlier periods, or breakdown distinguishing AI-assisted reports from other submissions. Without those figures, it is not possible to quantify the scale of the problem or determine whether the change responds to a sustained trend or a precautionary decision.

It is also unclear whether reports were considered invalid because the flaw did not exist, could not be reproduced, was already known, or was described with insufficient information. Those situations are not equivalent. Some may indicate an incorrect hypothesis; others may reflect a documentation or classification problem. Combining them under one label would obscure what kind of filter might be needed.

For the same reason, “AI slop” should not be presented as a technical category measured by Google. It is a value judgment, not a figure or verifiable criterion in the documentation supplied. The story can describe concern about a volume of low-utility reports, while preserving uncertainty about how many there were, how they were assessed, and what role AI played.

What makes a report verifiable

The complete official conditions Google may be applying during the pause have not been supplied. Still, it is possible to distinguish— as a general assessment principle, not a confirmed program rule—the information that helps others review a finding. The central requirement is that another person can understand the environment, repeat the steps, and observe the same behavior without relying on a conclusion written by a tool.

A useful submission should separate observations from hypotheses: identify the component and version examined, describe a reproducible configuration, list the minimum steps, and explain the observed result compared with the expected one. If the report claims a security impact, it should also show what security boundary is crossed and under what conditions, without overstating the scope. Testing should be safe and limited to systems for which the researcher has authorization.

Automated assistance may help explore code or improve the wording of a report, but it does not replace those checks. Fluent prose does not prove that a flaw exists; likewise, the involvement of a tool does not automatically invalidate a reproducible test. Assessment should focus on the technical evidence in the specific case and on the published requirements for the relevant program.

The duration of the pause remains unresolved

Available descriptions differ on whether the restriction is temporary or permanent. One presents it as a pause; another characterizes the block on AI-generated reports as permanent. The official material supplied does not resolve that difference. Nor is there enough information to establish whether both descriptions refer to exactly the same rule, to different categories, or to statements made at different times.

As a result, it is not possible to announce a return date or claim that Google has permanently prohibited every report in which AI was used. The most precise wording is that a pause affecting certain reports has been described, while its duration and exact conditions are not confirmed by the primary evidence available here.

The issue also has practical implications for researchers and maintainers. If a pause prevents submissions in a particular category, official instructions should clarify what to do with an urgent finding, whether it can be disclosed through another channel, and what information will be accepted. The supplied sources do not detail such routes, so it would be irresponsible to recommend a specific alternative channel or assume that rules for one category also apply to another.

What researchers and maintainers should watch for

For vulnerability researchers, the priority is to consult the current program conditions before investing time in a submission. If a category remains closed, the absence of an automated receipt should not be taken as confirmation that a finding has been assessed. If AI tools were used to prepare a report, documenting what was verified manually may help distinguish an automated suggestion from reproducible evidence, although no supplied official rule requires such a disclosure.

For maintainers, the issue highlights a different need: receiving reports that are easy to reproduce and leave little room for ambiguity. A template could request affected versions, configuration, minimum reproduction steps, observed results, and a justified account of impact. That is a reasonable editorial and operational measure, not a description of a specific Google policy. Teams should also avoid dismissing a finding solely because of how it was produced if the evidence allows it to be validated.

The most important missing confirmation would be an official notice specifying the affected category, effective date, duration or review date, exceptions, and acceptance criteria. An anonymized breakdown of submissions and rejections would also help assess whether the underlying issue was volume, poor reproducibility, or something else. Until that information appears, any more categorical explanation would go beyond what the available sources support.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.