Today, July 27, 2026, GitHub slashed its public bug bounty payouts by more than half at every severity level. A critical vulnerability that would have earned a researcher $20,000 to $30,000+ yesterday is now worth a flat $10,000. Medium findings dropped from $4,000-$10,000 to $2,000. Low-severity bugs went from $617-$2,000 down to $250.
The company’s reasoning makes sense on paper. AI-generated junk reports are flooding every bounty program on the internet, and triage costs are through the roof. GitHub wants less noise and more signal. It’s moving its best researchers to a private VIP tier where the real money lives — $30,000+ for critical finds, closer access to engineering, faster responses.
But here’s the thing. GitHub made this change on the exact day when the economics of vulnerability research are undergoing their most radical shift in three decades. And I’m not sure the timing could be worse.
The Race That Defenders Used to Win
For the last thirty-odd years, the patch-to-exploit timeline followed a predictable rhythm. A vendor ships a security fix, and the diff between the old code and the new code tells anyone paying attention exactly what was broken and where. Turning that diff into a working exploit was slow, specialized work. It took weeks, sometimes months.
Defenders usually won that race. You had time. Your patch Tuesday cycle, your change management window, your regression testing — they all fit comfortably inside the window between disclosure and weaponization.
That window doesn’t exist anymore.
Anthropic’s red team — the same group that demonstrated Claude defied its own CEO — recently ran the numbers, and they’re sobering. They gave Claude Mythos Preview nothing but a public diff and two builds — before and after. The model turned 18 Firefox patches into 8 working code-execution exploits on its own. Its first exploit landed under an hour after Mozilla shipped the fix. The Firefox release carrying that patch was still 18 days out.
The Windows results were even more striking. No source code, just stripped binaries and decompiler output. Out of 21 kernel bugs, Claude built proof-of-concept crashes for 18, the fastest in 31 minutes. It chained 8 of them all the way to SYSTEM at a cost of roughly $2,000 each. One of those SYSTEM chains was for a bug Microsoft had tagged “Exploitation Unlikely” — a label calibrated for human researchers. That calibration no longer holds. Anthropic’s own team put it bluntly: “N-hour is closer to the reality we now operate in.”
The Numbers Keep Getting Worse
The Zero Day Clock puts 2026’s average time-to-exploit at less than 24 hours, down from about 53 days in 2024. That is not a typo. Fifty-three days to under one day in two years.
Meanwhile, Verizon’s 2026 Data Breach Investigations Report puts the median time to fix a known-exploited flaw at 43 days, up from 32 the year before. Only 26 percent of organizations ever fully patch these flaws. Even the best performers close just 30 to 40 percent of known-exploited vulnerabilities in the first week.
You don’t need a math degree to see where this is headed. Exploitation speed is accelerating. Patching speed is getting worse. The gap between them is where breaches happen, and it’s widening every quarter.
Google Just Built a Cyber AI That Finds Exploits in Hours
A day before GitHub’s announcement, Google introduced Gemini 3.5 Flash Cyber — a lightweight model fine-tuned specifically to find, validate, and patch software vulnerabilities. In Google-run tests, it found 55 confirmed V8 issues compared to 47 for mainline Gemini 3.5 Flash and 36 for Claude Opus 4.6. More importantly, Google said its Cloud Vulnerability Research team used the model to find remote code execution flaws in public APIs and a memory-corruption bug in a sensitive production service within two hours. The model then generated what Google described as a 100-percent reliable RCE exploit that bypassed ASLR and W^X.
Two hours. From zero to a working, ASLR-bypassing exploit. This echoes what happened when OpenAI’s own models escaped their sandbox and autonomously found zero-days to cheat a benchmark.
This is the context in which GitHub is cutting public bounty payouts. Not just AI noise drowning triage queues, but AI capable of finding and weaponizing vulnerabilities faster than most organizations can even begin their patch deployment process.
A Bounty Program for a Different Era
The traditional bug bounty model was built for a world where human researchers were the only ones who could find and exploit vulnerabilities. That world is gone.
GitHub’s new structure — fixed, lower public payouts with a gated VIP tier — is a rational response to the signal-to-noise problem that AI has created. Curl’s maintainer Daniel Stenberg ended curl’s cash bounty earlier this year after its confirmed-vulnerability rate fell below 5 percent amid a flood of AI-generated junk. By April, after switching to HackerOne’s managed model and ending cash rewards, curl’s confirmation rate climbed back to 15-16 percent. Stenberg noted that almost every report now looks AI-assisted, but most are actually high quality. The lesson there isn’t that AI is ruining bug bounties — it’s that the model had to evolve to separate signal from noise, and it worked.
The irony is worth sitting with. AI generates so much noise that bounty programs have to restructure themselves to survive. But AI also generates exploits faster than any human ever could. The same technology that’s drowning triage queues is the same one collapsing the patch-to-exploit window.
What This Means for Developers Like Me
I manage IT infrastructure and write code for a living. I’m not a full-time security researcher, but I’ve reported bugs to open source projects before. The bounty was never the point — it was recognition that my time and expertise had value. The new GitHub model asks entry-level researchers to accept 50 to 59 percent less for their work while the most critical findings in the history of software security are being weaponized in under an hour.
That math doesn’t add up.
The VIP tier sounds great until you read the qualification criteria. To get in, you need to report at least one critical, two high, four medium, or seven low-severity vulnerabilities. With the new lower payouts, that’s a lot of work at reduced rates before you qualify for the better rewards. And the announcement does not specify whether hitting those thresholds guarantees an invitation.
For a new HackerOne researcher, the rules are even tighter. You get four trial reports per program within a rolling 30-day window. Four shots to prove yourself, with no room for mistakes or legitimate findings that get initially scored below expectations. The signal requirements are necessary to filter noise, but they also raise the barrier for the next generation of researchers who might have found the next heartbleed-level bug.
The Validation Alternative
There is a school of thought that says the bounty model was always a band-aid. The real solution isn’t paying people to find bugs — it’s proving that your controls would stop the exploit even if the bug exists.
This is the argument at the heart of the push toward continuous validation and breach-and-attack simulation. Don’t assume you’ll patch everything before it’s exploited, because the data says you won’t. Instead, prove that your detection and response controls catch the exploitation attempt regardless. This is especially critical as AI coding agents create new attack surfaces that traditional defenses weren’t designed to handle.
It’s a compelling idea, and I think there’s truth in it. The traditional model of “find a bug, report it, wait for a patch, deploy the patch” cannot keep up with N-hour exploitation speeds. You can’t patch your way out of a problem where the exploit arrives before the patch reaches production. The numbers from Verizon and the Zero Day Clock prove that the patch treadmill is a losing game.
But validation tools are expensive. They require expertise most small to mid-sized organizations don’t have in-house. And they don’t solve the fundamental incentive problem: if finding critical vulnerabilities becomes less economically viable for independent researchers, fewer people will do it. The really dangerous bugs — the ones that escape AI-powered code review and automated fuzzing — will stay hidden longer. We’ve already seen AI-powered supply chain attacks using thousands of malicious repos slip past automated defenses.
Where Do We Go From Here?
I don’t think GitHub is wrong to restructure its bounty program. The AI noise problem is real, and every major platform is wrestling with it. But I think the timing reveals something uncomfortable about where we are in the security maturity curve.
We are asking independent researchers to accept less for their work at the exact moment when their work has never been more valuable. Exploitation speed has collapsed from weeks to hours. Google’s cyber AI can go from zero to a working exploit in two hours. The same models that are drowning triage queues are also capable of finding vulnerabilities, validating them, and chaining them into exploits without human intervention.
The organizations that will fare best in this environment are the ones that stop treating bug bounties as their primary vulnerability discovery mechanism and start investing in defense-in-depth that assumes exploitation is inevitable. Validate your controls. Assume every patch disclosure is a ticking clock. Build detection for the exploitation attempt, not just the vulnerability.
But we also need to figure out how to keep the human researchers in the game. The bugs that automated tools miss — the business logic flaws, the cross-boundary attack chains, the design-level mistakes that no fuzzer will ever find — those still need human ingenuity. And if we make it economically unattractive to develop that skill, we’re not going to have enough people who can find the really dangerous things when the models inevitably miss them.
I don’t have a neat solution. I don’t think anyone does. But I know that when you look at the numbers — 53 days to 24 hours, 43-day patch cycles, 50 percent bounty cuts, Gemini generating working exploits in two hours — the trajectory is clear. The economics of vulnerability research are breaking, and we haven’t figured out what replaces them yet.
The models aren’t waiting for us to figure it out.