Google Freezes Its OSS Bug Bounty as AI Reports Swamp Reviewers── AI cut the cost of writing a report, not the cost of checking one; the defence is to demand reproducible proof at intake

On 1 October 2026, Google stopped accepting product vulnerability reports to its Open Source Software Vulnerability Reward Program (OSS VRP), saying AI and other automated submissions had surged and most of them were invalid. When AI makes filing a report almost free, who pays the cost of checking it? A small number of people on the receiving end pay it. Google has started to push that cost back to the sender by demanding reproducible proof at intake, and curl has taken the money away.

01Google's freeze shows the reviewers ran out before the AI reports did

The channel Google closed is one part of a programme that pays people who find security flaws in open-source code: the part that accepts reports on product vulnerabilities. Google gave its reason in plain terms. Automated submissions had risen sharply, and the vast majority were not valid. TechCrunch and Help Net Security both quote that explanation from the programme's rules page.

Writing a report now costs almost nothing, because AI will draft it. Checking a report has not got cheaper. A maintainer still has to make the bug happen on their own machine before anyone can say it is real, and that work takes time per report whether or not AI wrote the text. Put Google's two stated reasons together, a surge and mostly invalid reports, and I read the decision as the reviewers' hours running out before the supply of reports did.

The same thing happened elsewhere this year. curl, HackerOne and Nextcloud all shut or paused their reporting channels. Going by the reasons reported, I read each case the same way: the sender's effort was small and the receiver's effort stayed large.

For anyone who receives reports, applications or drafts produced with AI, I think the useful move is to ask for reproducible proof at the point of intake. The receiver cannot control how many submissions arrive. The receiver can decide what a submission must carry before anyone reads it.

02Google stopped taking product vulnerability reports but still pays for patches

Google's claim that most automated reports were invalid has to be read together with the scope of the stop. The rules page, as quoted by Help Net Security, says that from 1 October 2026 the OSS VRP no longer accepts product vulnerabilities.

That is the only thing that closed. Researchers are directed to Google's other reward programmes or to the Patch Rewards Program, which, as the name says, rewards fixes, and which stays open. Google also promised an update in the first quarter of 2027. It did not promise to reopen.

I set out this boundary first because a headline that says "Google ends its bug bounty" makes it sound as though every channel closed. Google withdrew one category of reward. It still pays for fixes.

One more limit on my own reading: I have not seen the text of Google's post on X directly. I treat the wording of the reason as TechCrunch and Help Net Security quote it.

03curl, HackerOne and Nextcloud hit the same limit in report triage

Pausing product vulnerability intake looks like one company's call. Yet in 2026 several other organisations closed their reporting channels too.

curl is open-source software used to move data across networks. Its lead developer, Daniel Stenberg, announced the end of its bug bounty on his blog on 26 January and closed it on 31 January. In April, Privacy Guides reported that HackerOne had paused submissions to its Internet Bug Bounty. In May, Decrypt reported that HackerOne and Nextcloud had suspended bounty programmes after waves of fake reports, and that at Bugcrowd the number of reports more than quadrupled over three weeks in March.

In all three places the people reading reports were a small group of maintainers or staff. At Bugcrowd, reports more than quadrupled in three weeks, and the number of readers does not rise with them. From the reasons in the table, I read every case as one where the reviewers' time ran short first.

I keep the scope to vulnerability reporting channels. Whether other industries' intake desks are seeing the same thing cannot be settled from these sources.

04Writing a report got cheaper; checking one did not

curl's own numbers show why the reviewers' time ran short.

According to Stenberg, in earlier years somewhere north of 15% of curl's submissions turned out to be confirmed vulnerabilities. From 2025 the confirmed rate fell below 5%. Every report that could not be confirmed still cost a maintainer the time it took to try to reproduce it.

A sender's work can now end at asking an AI to write the report and pressing send. If the report is wrong, the sender loses very little. A receiver's work is different. The receiver has to follow the steps in the report on their own setup and see whether the bug actually appears. However polished the text, that test cannot be skipped.

Stenberg wrote that the bounty had made it easy to cause trouble with almost no penalty. Where money is on offer, there is a reason to send a report even if the odds of being right are low. My own reading is that if each extra report adds a little to the expected payout, sending more of them is a sensible choice for the sender, and an expensive one for the receiver.

One caveat. Google wrote "automated submissions" and did not put a number on how many were produced by AI. I read the two as overlapping, but the size of the overlap has not been established.

05Google asked for reproducible proof; curl took the money out

The sender's effort is small and the receiver's is large. The two organisations tried to close that gap in different ways.

In March 2026, six months before the freeze, Google said it would require higher-quality proof for certain reward tiers. According to InfoWorld, that meant a reproduction in OSS-Fuzz or a merged patch. OSS-Fuzz is a service Google publishes that runs fuzz testing at scale across many machines to find bugs in open-source software. A report already reproduced there spares the maintainer from starting the test from scratch.

Google's condition makes the sender do the work of assembling proof before sending. curl's change removes the motive to send a report that is probably wrong. The tools differ. Google moves part of the cost of checking to the person who files; curl tries to cut the number of reports that need checking. Both reduce the receiver's load.

In the same month, InfoWorld reported that Google, Anthropic, AWS, Microsoft and OpenAI were together contributing $12.5 million to the Linux Foundation. I read that as an attempt to support the receiving side of open source from outside.

06Volume says nothing about quality, proof belongs at intake, and stopping intake is a legitimate tool

Put Google's reproduction requirement next to curl's ended bounty and three things follow for anyone whose job is to receive reports.

The number of reports does not show their quality

At Bugcrowd, reports more than quadrupled in three weeks. At curl, the confirmed share dropped below 5%. A rise in reports can no longer be read as a rise in real flaws found. Organisations that have counted reports as a measure of output or of threat will have to count something else. The reason is simple: AI has driven the cost of adding one more report close to zero.

Proof should be asked for at intake, before reading

An OSS-Fuzz reproduction or a merged patch can be checked for at the moment a report arrives. Send back the reports without one, and the maintainer's reproduction time goes only to reports that carry evidence. Once someone starts reading, the cost of checking already falls on the receiver, so proof has to be asked for before that.

Stopping intake is also a way to protect the people who check

Keeping a channel open forever is not the only form of responsibility. Google stopped one kind of intake, kept its other programmes running, and committed to an update in the first quarter of 2027. A stop that states its scope and the date of its next update is a different thing from abandonment.

07Terms for reopening, and whether the money covers the reviewing, are still not set out

Stopping intake, requiring reproduction, removing the bounty: all three responses appeared within 2026. The next step is still open.

Google's promise covers only an update in the first quarter of 2027. It has not said whether it will reopen, or, if it does, what proof it will require. If each programme demands different evidence, researchers will have to prepare differently for each destination. That is my inference; I found no source that has counted such differences yet.

The funding route is equally unproven. I could not find a source that says how many additional reviewers $12.5 million will pay for. The figure is InfoWorld's from March 2026, and I have not checked whether more has been added since.

What I will read next is the text of whatever rules Google publishes in 2027. If they spell out a proof requirement, then pushing the cost back to the sender at intake will have become written policy at one of the largest programmes.

Cheaper reports do not make checking cheaper; the receiving side keeps paying. Google moved part of that cost back to senders by requiring reproducible proof; curl removed the money that drew in reports likely to be wrong.

Plenty of other jobs involve receiving documents that AI helped write. When the volume rises, the first step is not to hire more readers but to write down what every submission must carry before it is read. That ordering is what I take from Google's freeze.