Google’s partial OSS bounty pause exposes a verification bottleneck

A small edit to Google’s public Bug Hunters repository marked a consequential change in its approach to open-source vulnerability disclosure. On 30 September 2026, an official commit added a stop notice to the Open Source Software Vulnerability Rewards Program, or OSS VRP, and replaced two product vulnerability reward ranges with dashes.

From 1 October 2026, Google stopped accepting new product vulnerability submissions through that programme. TechCrunch and SecurityWeek reported that Google attributed the decision to a significant increase in automated reports, most of which it said were invalid.

The scope matters. Google did not close its entire bug bounty operation, nor did every part of the OSS VRP stop. Product vulnerability reports submitted before 1 October remain unaffected. Supply-chain compromise reports are still listed as eligible, with typical rewards reaching US$31,337 for OT0 projects. Some findings involving Google Cloud repositories may qualify for the Cloud VRP, while Google also directs researchers towards other rewards programmes and its Patch Rewards Program.

The pause is nevertheless significant because it reveals an imbalance at the centre of AI-assisted vulnerability research. Tools can help produce candidate findings and plausible reports quickly, but deciding whether a reported flaw is reachable, reproducible and consequential still demands human attention. A submission that looks convincing without demonstrating genuine security impact transfers the difficult work of verification to maintainers and programme reviewers.

From evidence gates to an intake stop

Google launched the OSS VRP in 2022 to reward researchers who disclosed vulnerabilities in its open-source software. By March 2026, the company said the programme was receiving a massive surge in AI-generated reports. Its examples included reports that relied on hallucinated trigger conditions, identified errors in unreachable code, or described coding defects with negligible security impact.

Those examples illustrate the difference between a possible defect and a useful vulnerability report. An invented trigger, unreachable code path or coding error does not by itself demonstrate real security impact. Reviewers still have to examine the claim, reproduce the reported behaviour and assess its consequences before accepting or rejecting it.

Google initially responded by strengthening its rules rather than stopping submissions. Changes announced in March and April raised proof requirements for some reports and removed rewards or credit for product vulnerabilities and other security issues in the lower OT2 and OT3 project tiers.

The criteria retained on Google’s rules page ask researchers for detailed, reproducible evidence, including an affected version, reproduction instructions, impact, an attack scenario and a buildable proof of concept. For certain memory-corruption reports involving higher-tier projects, those criteria also describe reproduction through OSS-Fuzz or a merged patch.

These requirements move the burden of proof towards the submitter. They favour demonstrated security work over a plausible claim that maintainers must investigate from the beginning. The subsequent October pause suggests that the earlier filters did not resolve Google’s intake problem to its satisfaction.

There are important limits to that conclusion. Google has not published the number of submissions behind the pause, the proportion independently shown to be invalid, the size of any backlog or the number of staff hours spent on triage. The October reporting also referred to automated submissions, a broader category than AI-generated reports. Google’s March account explicitly identified an AI-report problem, but the public evidence does not establish that every report contributing to the later pause was produced by AI.

curl’s reversal complicates the picture

The experience of the curl project shows why AI assistance alone is a poor measure of report quality. In January 2026, curl lead maintainer Daniel Stenberg announced the end of the project’s monetary bounty. According to his account, the proportion of submitted reports confirmed as vulnerabilities had fallen from above 15 per cent in earlier years to below 5 per cent in 2025.

Stenberg reported that the programme had confirmed 87 vulnerabilities and paid more than US$100,000 over its lifetime. But the deterioration in its confirmed-report rate meant maintainers were processing many more unsuccessful claims for each useful result. curl ended bounty payments on 31 January.

The project then changed its reporting infrastructure. It returned private security submissions to HackerOne on 1 March, after finding GitHub’s workflow inadequate for its needs, but it did not restore monetary rewards.

By 22 April, Stenberg was describing a markedly different situation. He said report frequency had risen to about twice the 2025 level, while the confirmed-vulnerability rate had recovered to roughly 15 to 16 per cent. He assessed most submissions as AI-assisted and most as useful, with the conspicuously poor reports that had troubled the project earlier becoming less prominent.

That rebound does not identify a single solution. curl changed its financial incentives and reporting channel while AI capabilities were also developing. The figures are the maintainer’s own assessment rather than independently audited programme data, and the available evidence cannot isolate the effect of any one change.

It does show that AI use and low quality are not interchangeable. Assistance can contribute to unsupported speculation, but it can also help researchers locate and explain real defects. A programme that treats the presence of AI as proof that a report lacks value risks discarding useful work alongside noise.

No uniform industry experience

Accounts from other vulnerability programmes reinforce that caution. In July 2025, TechCrunch reported that HackerOne had encountered false positives generated with large language models that lacked real-world impact. In the same report, Bugcrowd and Mozilla said they had not experienced a comparable significant increase in low-quality or apparently AI-generated submissions at that time.

Those statements predate Google’s October 2026 pause and do not describe current conditions across the industry. Even so, the contrast cautions against treating the experiences of Google and curl as representative of every programme. The available evidence comes from a small number of organisational accounts, not a representative dataset using consistent definitions.

Google’s policy progression points towards one response: concentrate attention and rewards where researchers can demonstrate impact. Reproduction instructions, buildable evidence, affected versions and realistic attack scenarios help reviewers test a claim. Merged fixes and OSS-Fuzz reproduction can provide stronger evidence in the report categories where Google retains those criteria. Continuing to reward supply-chain compromise reports also directs resources towards a category Google has kept explicitly in scope.

Stricter gates carry their own cost. Producing a buildable demonstration or project-specific patch demands more effort and may require infrastructure that a legitimate researcher does not have. The reviewed sources do not measure whether Google’s earlier requirements reduced participation. Nor is there public data showing how many valid product findings will be redirected, delayed or never reported during the pause.

The unanswered design question

For researchers, the immediate rule is precise: new product vulnerability reports no longer belong in the OSS VRP. Before submitting, they need to establish whether a finding fits another authorised Google programme, a qualifying Cloud VRP route, the Patch Rewards Program or the supply-chain category that remains open. Whatever the route, Google’s criteria make reproducibility, affected versions and demonstrated impact central to a useful report.

Google says it will provide an update in the first quarter of 2027, but it has not promised that product vulnerability submissions will reopen. Its current rules page also retains older product vulnerability criteria beneath the dated stop notice, leaving documentation from the previous intake model alongside the controlling pause.

The challenge for the next design is not simply to block AI-written reports. Stenberg’s accounts of curl show that AI-assisted submissions can be useful even while their volume grows. The harder task is to preserve access for researchers with genuine findings while requiring enough evidence that cheap, plausible speculation does not consume the labour needed to validate and fix real vulnerabilities. Google’s next update will need to clarify whether product submissions will reopen and whether verification can scale without unduly narrowing the disclosure pipeline.

Reproducibility helps turn a plausible claim into evidence a reviewer can test; any practical testing must remain authorised and confined to controlled environments. Pursue the underlying security principles through The Hack Academy’s online cybersecurity training programme, which offers self-paced learning in internet vulnerabilities and penetration testing, with practical exercises alongside theory.