Starting October 1, 2026, Google stopped accepting new product vulnerability reports through its OSS VRP, the program that pays rewards for vulnerabilities in open-source software. Supply chain reports, and product vulnerability reports submitted by September 30, are not affected by the suspension. This spring, Google had already narrowed the program's scope and demanded stronger evidence, such as reproduction steps, in response to a surge in AI-generated reports. The latest move shifts the program from tightening quality requirements to screen reports to halting new product vulnerability intake altogether so the program can be reviewed. The question for future program design is how to connect AI, which can accelerate vulnerability discovery, to the human work of verification and remediation.
Product vulnerability intake is paused; supply chain reports continue
Google's current rules state explicitly that new product vulnerability reports are no longer being accepted. This category covers problems in the design or implementation of open-source software published by Google that significantly affect the confidentiality or integrity of user data. Google has not ended all of its vulnerability reward programs, nor has it closed a common channel for accepting vulnerabilities in open source in general.
The OSS VRP launched in 2022 and covers public repositories in GitHub organizations owned by Google, among other targets. Product vulnerability reports submitted before October 1 are unaffected by the suspension. In addition, for some Cloud-related repositories that affect Google Cloud products, product vulnerability reports may be accepted under the separate Cloud VRP. That does not mean any code related to Cloud can simply be redirected there.
The supply chain reports that Google continues to accept concern who can modify the software that gets distributed. Examples include misconfigurations that allow a repository's main branch to be overwritten, mechanisms that allow tampering with build artifacts distributed to users, and leaks of credentials used to publish packages. The location and route of attack differ from flaws in the product's internal code itself. Reports of problems that could lead to a compromise of the software supply chain remain within the program's scope.
However, a supply chain finding does not automatically earn a reward. The rules require that the conditions for an actual compromise be met, such as an external contributor being able to bypass the approval process when getting changes merged. Just because product vulnerability intake has stopped, a report will not be accepted merely by recasting a flaw in the same code as a supply chain issue.
From tighter quality requirements in spring to a halt in October
In spring 2026, Google's OSS VRP narrowed the scope and tightened the evidence requirements for product vulnerability reports, and on October 1 it stopped accepting new ones entirely. The spring measures required verifiable evidence for reports on major projects and removed product vulnerabilities in lower-priority projects from reward eligibility. The October change goes further, suspending new intake for product vulnerabilities as a whole.
According to the spring rule update blog, reports were increasing in which AI had fabricated incorrect triggering conditions, as well as reports in which an error did exist in the code but had little effect given the project's security design. One example cited was a buffer overflow in processing that an attacker cannot reach. Google acknowledged AI's ability to assist security research while asking researchers to verify its output themselves.
Google classified projects into OT0 (major), OT1 (important), OT2 (standard), and OT3 (low priority). For memory corruption reports in OT0 and OT1, an exact reproduction procedure using an existing OSS-Fuzz target, or a fix merged into the target repository, became necessary. In an April addendum, product vulnerabilities and "other security issues" in OT2 and OT3 were removed from eligibility for rewards and public credit. Google also explained that its security team would not triage or verify product vulnerability reports in these lower tiers.
Comparing the "April 2026 Update" and "New Acceptance Criteria" in the spring blog with the "Product vulnerabilities" section of the current rules, category by category, the changes are as follows.
| Report category / status | Spring 2026 revision and April addendum | From October 1, 2026 |
|---|---|---|
| Product vulnerabilities in OT0 and OT1 | Memory corruption requires an exact reproduction procedure using OSS-Fuzz, or a merged fix | New intake of product vulnerabilities suspended |
| Product vulnerabilities in OT2 and OT3 | Not eligible for rewards or public credit; Google's security team does not triage or verify | Included in the suspension of new product vulnerability intake |
| Submissions made before October 1 | Handled under the conditions at the time of submission | Not affected by this suspension |
| Supply chain reports | Continued emphasis on source and build compromise and credential leaks | Not covered by this suspension of product vulnerability intake |
This comparison shows how the acceptance conditions changed; it does not show by what percentage the spring measures reduced the number of reports. The reproduction requirement also applied to memory corruption reports in OT0 and OT1 at that time, and Google was not requiring a merged fix for every vulnerability. Google has not explained the suspension by quantitatively demonstrating the effect of the stricter requirements, so it cannot be concluded that the spring quality measures failed.
Why "reproducible" is not enough
In OSS-Fuzz's official reproduction procedure, the input file that triggered the problem is fed to the target program, and Docker is used as needed to align the build environment. When investigating memory corruption, tools such as AddressSanitizer, which detects invalid memory access, are used. If the target code, input, and detection method are all in place, others who read the report can easily reproduce the phenomenon. After a fix, the same input can be supplied to confirm that the problem has been resolved.
Even if AI generates a plausible explanation, that alone is not evidence that the program was actually run and the problem confirmed. The spring requirements can be seen as a mechanism that, rather than accepting reports on the strength of persuasive text alone, had reporters themselves take on part of the reproduction and fixing. The aim was to reduce the burden on the receiving side of investigating triggering conditions from scratch.
Still, a program crashing and actual harm to users are separate matters. It is necessary to determine whether an attacker can get input to reach that code, and whether data confidentiality or integrity would actually be compromised in real-world use. The "error in code unreachable by an attacker" that Google gave as an example in spring illustrates that difference concisely.
The current rules ask for a buildable proof-of-concept, along with the affected versions, reproduction steps, the impact of the problem, and the conditions under which the attack succeeds. Even if a fix has already been merged into the repository, that alone does not guarantee a reward. The fact that the code could be fixed and the fact that a security impact sufficient to qualify for a reward was demonstrated are different things.
At curl, low-quality reports fell, but "real work" increased
curl shows that problems around AI and vulnerability reports can continue even after a bug bounty program ends. In an explanation on January 26, developer Daniel Stenberg announced that the bounty program would end on January 31, 2026. According to him, in 2025 the share of submitted reports that could be confirmed as real vulnerabilities fell below 5%, and the work of separating true reports from false ones consumed a great deal of time and mental energy. Although the bounty ended, curl continued to accept vulnerability reports themselves.
However, a report on April 22 showed that the situation had changed. He explained that low-quality AI-generated reports were no longer a major problem and that report quality had improved. The share confirmed as vulnerabilities had recovered to around 15 to 16%, while the frequency of reports had roughly doubled compared with 2025. This is Stenberg's own account of curl and does not indicate the situation in Google's program.
Stenberg believed that at that time almost all security reports involved some form of AI assistance. This was an inference based on clues such as the wording of reports and detailed duplicate reports, not the result of a rigorous count of the tools used. At least in his experience, AI-assisted reports and high-quality reports were compatible.
The problem that emerged next was a shortage of people to fix the vulnerabilities that had been found. He worries that if valid reports increase without any increase in maintainers, cases awaiting handling will pile up. Eliminating low-quality reports reduces the wasted effort spent verifying whether a report is genuine. But if more genuine vulnerabilities are found, the work required for fixes and releases grows in turn. curl's experience shows that, in thinking about bounty programs for the AI era, report quality and the volume the receiving side can handle need to be considered separately.
In a redesign, the burden from report to fix is what to watch
Google says it will provide an update on this part of the OSS VRP in the first quarter of 2027. It has not, however, decided to resume intake at that time. For now, it points to other VRPs that may apply depending on the scope of impact, and to the Patch Rewards Program, which pays rewards for improving the security of open source. For researchers, the practical change for the time being is figuring out which program they can report a discovered problem to.
In evaluating future program design, looking only at whether AI use is permitted is not enough. How will a mechanism for confirming reproduction before submission, like the spring OSS-Fuzz requirement, be built in? Who will confirm the conditions under which an attack actually succeeds, and the security impact? And how far can researchers and maintainers be involved in the work of turning confirmed problems into actual fixes? Holding down the number of reports and increasing the number of issues that can actually be fixed need to be evaluated separately.
If new conditions encourage verified inputs and contributions to fixes, and the people and mechanisms to absorb them are also put in place, the growth in vulnerability discovery driven by AI could be turned into real improvements in security. In the update Google presents in 2027, it will be worth watching not only under what conditions reports will be accepted, but also how far it shows a mechanism for turning confirmed vulnerabilities into actual fixes.