AI slop submissions force Google to freeze its open

* Google stopped accepting new product vulnerability reports through the OSS VRP.
* The pause is due to a rise in automated submissions that are largely invalid.
* New product vulnerability reports will no longer be accepted to the OSS VRP as of October 1, 2026.
* Reports submitted before October 1 are not affected.
* Product vulnerability reports may still be accepted via the Cloud VRP for some Google Cloud repositories impacting Cloud products.
* Researchers should submit findings to other VRP programs or the Patch Rewards Program.
* The criteria for accepting reports depend on the project tier and vulnerability subcategory.
* A design or implementation issue in Google OSS causing a product vulnerability affecting user data is in scope for the program.

The situation reveals a tension between maintaining the integrity of a security reward program and managing the influx of submissions generated by automated systems, highlighting a friction point between administrative control and the reality of modern vulnerability disclosure. The shift signals a recognition that an entirely open submission process is vulnerable to systemic exploitation by non-human actors, forcing a temporary suspension to re-establish quality control. This move implicitly acknowledges that the volume of submissions risks diluting the value for legitimate researchers and maintainers.
The pattern observed is one where large-scale systems attempting to manage decentralized information (like bug bounties) must intervene when the input mechanism becomes corrupted by automated, low-quality noise. The core implication is that the pursuit of security disclosure requires filtering mechanisms; however, this filtering introduces new potential vectors for bias or exclusion, as the boundary between valid human contribution and systemic noise becomes increasingly blurred. Who benefits from this pause? It likely shifts the burden of initial quality assurance onto Google, while researchers navigate an interim system. The ongoing necessity to rely on external reward programs demonstrates a reliance on parallel structures when primary systems fail under pressure.
What processes are currently in place for differentiating human-driven versus AI-driven submissions without resorting to outright blocking, and how do these differentiation methods evolve as automation becomes more sophisticated? If the focus remains on remediation (the Patch Rewards Program) rather than pure disclosure rewards, does this structure inadvertently incentivize vulnerability reporting that is more easily verifiable or less prone to automated generation?