AI Broke the Bug Bounty
On October 1, 2026, Google stopped accepting product vulnerability reports through its Open Source Software Vulnerability Reward Program. The reason, in Google's own words, was a pause caused by "a significant rise in automated submissions, the vast majority of which are not valid."
Translation: machines were writing bug reports, most of them were wrong, and paying a human being to sort through them had stopped making economic sense. So the world's largest bug bounty programme stopped paying humans to read them.
Google is not the first. curl ended its HackerOne programme in January. Intel replaced a bounty paying up to $100,000 a flaw with a disclosure programme offering nothing at all. And on September 30, Google shipped a model advertising the ability to autonomously find, validate, and patch critical software vulnerabilities. Both things are true, which is the most Google sentence ever written.
This is a bigger deal than it first appears, because the bug bounty was the mechanism the web's security depended on. Here is what happened and what it means for the website you are probably reading this on.
What Google actually closed
Google's bounty had two halves, and only one closed. Product vulnerabilities in Google's open-source projects were closed to new submissions from October 1, 2026. Supply-chain reports, which cover tampering with a repository or its build pipeline, remain open and carry the top prize. Reports submitted before October 1 are unaffected.
The detail people miss is that Google did not stop paying at all. It redirected. Researchers are being pointed to the Cloud VRP for flaws in Google Cloud's open-source repositories, the AI VRP, and the Patch Rewards Program, which pays for security fixes rather than for findings. Payouts under the old programme had ranged from $100 to $31,337 since 2022, and the supply-chain tier is where the top prize lives, starting around $3,133 depending on the project.
There is also no reopening date. Google has said it will keep reformatting the programme and commit to an update in the first quarter of 2027. It has not described that as a redesign, and it has not described it as a reopening.
For context on the scale of what is being conserved: Google paid a record $17.1 million to 747 researchers through its vulnerability programmes in 2025, up 40% on the year before, and $81.6 million since 2010.
The curl numbers are the real evidence
Google's announcement gives a reason. curl gives data.
Daniel Stenberg, who leads the curl project, ended curl's HackerOne bounty on January 31 after nearly seven years. In the post explaining why, he tallied the results: 87 confirmed vulnerabilities and more than $100,000 paid out. Then he described what changed. In 2024, more than 15% of submissions were confirmed as genuine. In 2025, that fell below 5%.
That is the entire story in two numbers. A third of the queue at fifteen percent confirmation is a research programme with a filter. Four percent is not a research programme.
| Programme | Status | Stated reason | Practical effect |
|---|---|---|---|
| Google OSS VRP, product flaws | Closed to new submissions | Overwhelming automated, invalid reports | Research redirected to three other programmes |
| Google OSS VRP, supply chain | Open | Unaffected | Top $31,337 prize now behind this door only |
| curl on HackerOne | Ended January 31 | Confirmation rate fell below 5% | 87 real bugs found over seven years, unpaid queue after |
| Intel | Rewritten in September | None given | Up to $100,000 replaced with no reward at all |
Intel gave no reason for its change and has not linked it to AI reports, so any connection there is inference rather than fact.
At that confirmation rate, you are not running a bug bounty. You are running an essay competition with a prize attached, and paying a moderator to read every entry.
It is worth being fair to the researchers here, because the number hides a real group. Curl's confirmation rate collapsed, but the total volume of genuine work did not obviously vanish. Some of it went to programmes that still pay, and some of it plausibly stopped being submitted at all, because a researcher who cannot get paid for the work will not keep doing it indefinitely. That second group is invisible in every statistic published so far.
The awkward part for Google specifically
Here is the contradiction worth sitting with.
On September 30, 2026, Google announced Gemini 4 Argon with the claim that it "can autonomously find, validate, and patch critical software vulnerabilities." Thirty-one days later, Google stopped paying human researchers to find and validate those same vulnerabilities, because the automated reports were overwhelming and invalid.
These are not contradictory claims about capability. They are contradictory claims about cost. Argon, run by a team that checks its output, may well find real bugs. The same class of model, pointed at a bounty page by somebody hoping for a payout, produces a confident write-up of a vulnerability that does not exist. The programme cannot tell those two apart until a human has done the expensive part.
Google is not alone in funding both sides of this. In March it put up $12.5 million alongside Amazon, Anthropic, Microsoft/GitHub and OpenAI, run through the Linux Foundation's Alpha-Omega and the OpenSSF, to help maintainers cope with the load. Anthropic's red team measures the same capability in rival models and has rated a Chinese open-weight model's hacking skills publicly.
What has gone missing is the boring part. Not the finding, and not the fixing. The validation.
Follow-through: one bug class, five organisations
While the bounty debate ran, a single researcher was finding the same vulnerability class over and over. Syed Anas Mohiuddin reported the same server-side request forgery pattern in five separate Model Context Protocol servers: Google's MCP Toolbox for Databases, JPMorgan's documentation-search server, Weaviate, the French government's DINUM open-data server, and a Wazuh MCP server run by the city government of Tangerang in Indonesia.
| Organisation | What was wrong | Severity | Status |
|---|---|---|---|
| HTTP client with no redirect policy and no target IP checks | 8.0 high | Fixed with DNS rebinding guard and IP allow/block lists | |
| JPMorgan | One tool checked domains, its sibling fetched any supplied URL | Medium | Confirmed and fixed |
| Weaviate | Endpoint settings accepted arbitrary hosts | Not stated | Restricted to Google API hosts |
| DINUM, France | Fetched URLs supplied by data producers, which could point inward | Not stated | Hardened, credited to the reporter |
| Wazuh, Tangerang | Advertised SSRF protection that never resolved hostnames | High | Reported September 3 |
Google's flaw is CVE-2026-14540, affecting versions 0.3.0 through 1.4.0. Five further MCP servers under the US General Services Administration were reported on September 2 and remain in triage.
One of them, the Wazuh server, advertised SSRF protection. The protection rejected literal IP addresses and never resolved hostnames, which is the digital equivalent of locking the front door and leaving a hole in the garden wall.
The JPMorgan case is instructive in a different way. That server was forked from an AWS project which never fetched a caller-supplied URL at all. In the fork, somebody added a sibling tool that fetched anything it was given, while the tool next to it correctly checked domains against an allowlist. The safe pattern was right there in the same codebase and it got copied wrong.
And five MCP servers belonging to the US General Services Administration, covering veterans' benefits claims, Medicare data, regulations.gov, federal spending and a health dataset, were reported on September 2 and were still sitting in triage at the time of writing.
What this means if your website runs open-source code
Which it almost certainly does. Your website is running on a framework, a CMS, a theme, and somewhere between twenty and two hundred libraries, all maintained by people who are frequently unpaid.
The honest read of this story is not that open-source software got less safe overnight. It is narrower and more specific. Triage got cheaper. Real bug hunting now competes for funding against AI output that is confidently wrong. The projects best able to absorb that are the large ones, and the ones most affected are the small volunteer-run dependencies sitting at the bottom of everyone's stack.
Your website is running open-source code right now. Somewhere in the stack there is a dependency maintained by someone who got paid a few hundred dollars for finding a bug in 2022 and has read several thousand AI-written claims since. That is the supply chain.
The practical response is unglamorous and it has not changed. Keep the dependency count small. Pin versions instead of tracking latest. Update on a schedule rather than when something breaks. Watch advisories for the short list of dependencies that handle authentication, payments, file uploads, and user input, because those are the ones where a server-side request forgery turns into something much more expensive.
If you want this done properly rather than hopefully, our SEO and technical audit service covers the dependency and performance side, and the web development service covers ongoing maintenance. The cost estimator will price either in about a minute.
What we still do not know
Whether real research has actually stopped. Every number published is about the ratio of valid to invalid reports. None of them measure the volume of genuine findings that were never submitted. That is the number that would matter and it does not exist yet.
Whether the fix holds. Google's answer is a reformat and a Q1 2027 update. The proposals circulating in the affected projects are more concrete: a published policy on AI-assisted reports, and a working proof of concept required before triage begins. Those address the actual problem rather than the symptom, but they are not Google's official position.
How far this spreads. Two programmes have changed and one has paused. Most bug bounty programmes are smaller and have less margin, so the pressure to stop paying for reports that need human validation is not uniquely Google's problem.
Frequently asked questions
Why did Google pause its open source bug bounty?
Google stopped accepting product vulnerability reports through its Open Source Software Vulnerability Reward Program on October 1, 2026. Google's stated reason was a significant rise in automated submissions, the vast majority of which were not valid. Supply-chain reports and anything submitted before October 1 were unaffected.
What is a bug bounty program?
A bug bounty is a programme that pays independent researchers to find security flaws in software. Reports are triaged, confirmed vulnerabilities are fixed and paid for, and a portion of submissions is normally rejected as invalid. The confirmation rate is the practical measure of whether a programme is still worth operating.
Does this make open source software less secure?
Not by itself. Reducing the number of invalid reports improves triage efficiency for real findings. The risk is narrower and more specific: money that previously funded human vulnerability research is being redirected, and maintainers of smaller projects may end up absorbing unpaid reports from programmes that have stopped paying for them.
What is SSRF and why was it found in so many MCP servers?
Server-side request forgery is a flaw where an application is persuaded to make an outbound request to an address the attacker chose, including internal network addresses and cloud metadata endpoints. One researcher found the same class of flaw independently in five separate MCP servers, which points to an implementation pattern being copied rather than to five unrelated mistakes.
What is the Model Context Protocol?
The Model Context Protocol is an open standard that lets AI applications connect to external tools and data sources through a common interface. Servers built on it are recent, numerous, and often written quickly, which is the normal condition under which a common vulnerability pattern appears across many implementations at once.
Does this affect my website?
Indirectly. Most small business websites run on frameworks, plugins and libraries maintained by volunteers, and the projects able to afford paid triage are the ones least affected by reduced bounty funding. The practical response is ordinary hygiene: fewer dependencies, pinned versions, regular updates, and monitoring of advisories for anything that touches user data.
How can a small business check its website dependencies?
Inventory what the site actually loads, pin version numbers rather than tracking latest, run updates on a schedule rather than reactively, and subscribe to advisories for the handful of dependencies that handle authentication, payments, file uploads and user input. A short list of critical dependencies is far more useful than a complete dependency graph.
Will Google reopen the bug bounty program?
There is no reopening date. Google has said it will continue reformatting the programme and commit to giving an update in the first quarter of 2027. In the meantime researchers are being pointed to the Cloud VRP, the AI VRP and the Patch Rewards Program, which pays for fixes rather than for findings.
Related reading
- OpenAI Is Now Watermarking AI Text in the EU — the same trust problem, on the content side.
- Google's DESIGN.md: What the Design System Spec Means — how structured intent beats guesswork.
- SEO Audit Services — the technical and performance side of a site review.
- Web Development — building and maintaining what your site runs on.
- Website Cost Estimator — price your own scope in about a minute.