Google has stopped accepting new vulnerability reports for its open source software. Not because the flaws ran out. Because the reports did.
On October 1, the company paused product vulnerability submissions to its Open Source Software Vulnerability Rewards Program, the scheme that pays outside researchers who find security flaws in Google's open source projects. The reason, in Google's own words, was a "significant rise in automated submissions, the vast majority of which are not valid." The program stays paused until at least early next year. Google has promised an update in the first quarter of 2027.
Read that again. One of the largest bug bounty programs in the industry did not fall to an attack. It was buried under paperwork, much of it written by machines, describing bugs that do not exist.
A pause, not a shutdown
The distinction matters, because headlines travel faster than footnotes. Google has not closed its bug bounty operation. Reports already inside the system are still being handled. Supply chain vulnerability reports, a separate and increasingly sensitive category, are still being accepted under the same program. And researchers are being pointed toward Google's other reward schemes, which remain open.
What has closed is the front door for new product vulnerability reports in the open source program. That program, launched in 2022, covers some of the most widely used software Google maintains, including the Go programming language, the Angular framework and the Fuchsia operating system. These are not side projects. Code from these projects sits inside products and services used far beyond Google's own walls, which is exactly why the company paid outsiders to attack it on paper first.
The pause was announced in a short post on X and on the program's website. Short, but not casual. Companies do not suspend a security intake channel lightly, because every week it stays closed is a week in which a genuine, serious flaw might sit in a researcher's notebook instead of in Google's triage queue.
Google is betting the opposite risk is now larger. According to reporting cited by TechCrunch, engineers and open source maintainers were overwhelmed by reports that were invalid or contained hallucinated details, flaws described in confident language that fell apart the moment anyone tried to reproduce them. Triage is skilled, slow work. Every invented bug still has to be read, checked and closed by a human before the next report gets its turn.
The warning was a year old
Nobody inside security can honestly call this a surprise. Last year, researchers were already warning publicly that AI-generated reports were becoming a serious burden on bug bounty programs. The economics are brutally simple. Writing a plausible vulnerability report used to take skill and time. A language model cuts that cost to almost nothing. Checking the report, though, still takes a skilled person the same time it always did.
So the flood arrived. Some of it is lazy: people pasting model output into submission forms, hoping something sticks and pays. Some of it is automated at a scale no individual could manage, scripts generating report after report across projects. And some of it is honest beginners who trust the tool too much, submitting whatever the model produced without testing whether the flaw was real.
The result looks the same from the maintainer's chair. A queue full of noise. Real findings somewhere inside it, harder to spot, slower to reach.
Google is not the first to push back. The curl project, whose data transfer tool sits inside billions of devices, spent much of the past year in a public argument with this exact problem, tightening its rules after waves of low-quality AI-assisted reports. Other long-running bounty schemes have cut or restructured payouts in the same period, for the same reason. The pattern has a name now, and the name is not flattering to the machines: slop.
It sits oddly alongside the wider debate about automated systems acting without supervision. Regulators are asking what happens when machines act on their own. Maintainers have been living a smaller, duller version of the same question for months, one report at a time.
What a hallucinated bug actually costs
A fake vulnerability report is not harmless. It consumes the scarcest resource in open source security: expert attention.
Take a single invented report. A maintainer reads it. They check the code path it describes. They write a test, or ask for one. They go back to the reporter, who often cannot explain the finding because they never understood it. Days pass. Multiply that by hundreds of submissions and the cost stops being an annoyance and becomes a structural problem. The people best qualified to fix real flaws are spending their week disproving imaginary ones.
There is a second cost, quieter and worse. When a queue fills with noise, response times stretch for everyone, including the researcher who found something genuine and dangerous. Security people have a phrase for the end state: the signal drowns. A program that cannot tell a critical flaw from a fabricated one has, in practice, stopped working, whatever its website says.
Google's pause is an admission of that arithmetic. Closing intake is drastic. It was still cheaper than reading everything.
The episode also complicates a story the industry likes to tell about itself. Open source security has improved enormously over the past decade, and shared standards have been part of that. But standards assume good-faith participants on both sides of the form. Automation broke that assumption at scale, and nobody has yet designed the form that survives it.
What happens next
Google says an update will come in the first quarter of 2027. It has not published a submission count, a rejection rate, or the criteria the program must meet before the door reopens. Those missing numbers matter. Without them, other programs cannot tell whether Google's flood was a freak wave or the new water level, and the smart money, frankly, is on the water level.
The likely fixes are already being debated in the open. Verified identity for reporters. Reputation scores that follow researchers across programs. Limits on submissions from new accounts. Automated screening that fights fire with fire, using models to reject model-written reports before a human sees them. Each option has a cost. Identity checks push away talented researchers in places where anonymity is protection, not mischief. Reputation systems favour insiders. Automated screening will make mistakes in both directions, and a wrongly rejected critical flaw is the nightmare case nobody wants to own.
There is also a question for the AI companies themselves, and it is not rhetorical. The same tools flooding these queues are marketed as security assistants. Some of them genuinely find real bugs; skilled researchers using them well are part of the ecosystem, not the problem. The line is verification. A finding you have reproduced is research. A finding you have not is a rumour with a submission button.
For now, the practical advice for researchers is plain. Google's other programs are open, supply chain reports are still wanted, and a well-documented, reproducible flaw will always find an audience, at Google or elsewhere. The researchers who built reputations the slow way, through the kind of work examined in enterprise API security testing and similar hard disciplines, are not the ones this pause punishes. It punishes volume. That may be the point.
And there is a wider read here. Open source runs on volunteered attention, and attention does not scale the way generation does. One person with a script can now produce more text than a hundred reviewers can assess. Google, with all its resources, decided it could not read everything arriving at one of its own programs. Smaller projects, with two maintainers and a day job, never stood a chance. What they do next, and whether the ecosystem builds them better defences than a pause button, is the real story to watch into 2027.
One part of the program keeps its doors open through the freeze, and the choice is telling. Supply chain reports are still being accepted. So are reports already in the system. That is Google quietly ranking its fears. A flaw smuggled into a widely used library or build process can travel into thousands of products before anyone notices it, which makes supply chain findings the reports the company least wants to discourage. Product bugs in its own projects matter. Poisoned dependencies matter more, and the exception carved out of this pause says so.
Researchers, meanwhile, are adjusting in public. The advice circulating among experienced hunters this week is unglamorous: reproduce the flaw yourself, attach the smallest test case that proves it, and write the report in your own words, in your own voice. A clean proof of concept has become a kind of passport. It signals that a person stood behind the finding and can answer questions about it, which is exactly what triage teams say they can no longer assume. Programs elsewhere are watching Google's experiment closely, because if a quarter or two of quieter queues produces better fixes, the pause will not stay a Google story. It will become the template everyone reaches for when the flood rises, and the age of the open, take-everything submission form will be over.
A bounty programme drowning in low-quality reports leaves real vulnerabilities unreviewed for longer, and someone is always collecting those. Nation-state espionage groups are accelerating harvest-now, decrypt-later exfiltration, stockpiling what they cannot yet use. While disclosure pipelines clog, the practical fallback is defense that assumes the bug ships anyway — runtime application self-protection against zero-day memory exploits is designed for precisely that assumption. The same week showed the other side of the same pressure, when four WordPress plugins let unauthenticated attackers take over admin accounts outright: defenders short on time, flaws piling up at once.
