GitHub is changing the economics of finding bugs on GitHub.
On July 22, the company announced a restructure of its bug bounty program: static public payouts, a permanent private VIP program, and a HackerOne signal requirement for public submissions. Reports filed before the change are grandfathered, but GitHub says reports submitted on or after July 27, 2026 will be assessed under the new structure.
The easy read is that GitHub is cutting rewards. The more useful read is sharper: the bounty market is now fighting report inflation.
Security teams are no longer just sorting through earnest but weak reports. They are sorting through AI-assisted reports, shallow scanner output, duplicate claims, non-impactful findings and issues that belong to customer configuration rather than the platform itself. GitHub is trying to make the queue smaller without closing the door on serious new researchers.
GearPulse’s view: this matters because it is a preview of how security work changes when AI makes plausible-looking reports cheap. Platforms still need outsiders. They just need outsiders who can prove impact.
The new payout shape
GitHub is creating two visible tracks.
The public program moves to fixed payouts: $250 for low, $2,000 for medium, $5,000 for high and $10,000 for critical vulnerabilities. GitHub says static payouts reduce uncertainty and keep review overhead down, while still leaving room for discretionary bonuses.
The new permanent VIP program is invite-only and pays more: $1,000 for low, $7,500 for medium, $20,000 for high and $30,000 or more for critical findings. GitHub says researchers can qualify through consistent high-quality impact: one critical, two high, four medium or seven low findings.
| Track | Low | Medium | High | Critical |
|---|---|---|---|---|
| Public program | $250 | $2,000 | $5,000 | $10,000 |
| VIP program | $1,000 | $7,500 | $20,000 | $30,000+ |
The public path is still there. It is just more gated. GitHub says HackerOne’s signal requirement will limit submissions from researchers who have not yet met the platform threshold, while still giving them up to four initial submissions to establish a track record.
Why the change feels bigger than GitHub
Bug bounties have always had a noise problem. A program open to the internet will receive false positives, duplicates, low-impact issues and reports without working proof. The AI era makes that worse because generating a polished report is easier than doing the difficult part: proving exploitability, understanding scope and explaining why the bug matters.
That is why GitHub’s wording is important. It is not rewarding volume. It is rewarding signal.
This connects directly to GearPulse’s recent MCP quality coverage. Agent tools can look usable while hiding weak labels, vague schemas and low-quality behavior underneath. Bug reports now have a similar problem. A report can look complete while carrying very little judgment.
For developers, the lesson is uncomfortable but useful: automation is now table stakes, but validation is the product. A security report that merely names a scary class of bug is not enough. A useful report shows the route, the boundary crossed, the affected asset, the privilege change, the impact and the fix direction.
Researchers should read the incentive
For serious bug hunters, the new structure is not all bad. Fixed payouts remove some ambiguity, and the VIP tier gives a path to higher rewards and faster response for people who repeatedly deliver. The tradeoff is that casual, speculative submissions become less attractive.
That is probably healthy for mature programs. GitHub is a high-value target with a large security team, a long-running program and a deep backlog of institutional knowledge. If a report does not show impact, it costs time that could have gone to the next real bug.
The risk is that signal requirements can make the first step harder for talented newcomers who have not yet built HackerOne history. GitHub is trying to soften that with the four-submission runway, but it still changes the feel of the public program. The bounty ladder is becoming more like a reputation market.
| If you are a… | The practical takeaway |
|---|---|
| New researcher | Spend more time proving impact before submitting; four weak reports can close your window. |
| Experienced hunter | Consistency is now directly tied to access and higher payouts. |
| Security team | Expect more programs to copy signal gates and static tables. |
| Developer | Your bug-fix priority should start with demonstrated exploit path, not report polish. |
What users should care about
Most GitHub users will never file a bounty report, but the change still matters because GitHub is the platform underneath a huge share of modern software. Better triage affects how quickly real vulnerabilities are handled. Poor triage burns time, and time is a security resource.
There is also a cultural point. AI can help researchers test hypotheses, read code, build proof-of-concept ideas and write clearer submissions. But if it floods programs with guesswork, it makes security worse for everyone. The winning researchers will be the ones who use automation to get to evidence, not to skip evidence.
Bottom line
GitHub’s bug bounty reset is not just a pay-table update. It is an early answer to the AI-noise problem in security research.
My take: the future of bug bounties will be less open-volume and more proof-driven. That may feel harsher, but it also respects the researchers who do the hard work. The best report was never the longest one. It was the one that made the risk impossible to ignore.