Bug Bounty Reward Tiers Researchers Actually Trust

To set bug bounty reward tiers researchers trust, do four things: map severities to a scoring model (CVSS or a context-specific one), anchor each tier to benchmark data with min and max ranges instead of a single number, publish and lock the table and scope so they cannot silently change after submission, and reserve cash for impact while recognizing low-impact work in a separate lane. The failure that destroys trust is not paying too little. It is repricing finished work after a researcher already submitted, fixed, and got credited under the old numbers.

That distinction is the whole story of the first half of 2026. In May, HackerOne took an axe to the Internet Bug Bounty (IBB), slashing rewards across every severity tier, and a chunk of the backlash landed on timing, not amount. If you run a vulnerability disclosure program (VDP) or a young bug bounty and you are watching AI-generated reports pile up in your inbox, you are afraid of two things at once: getting buried in junk, and setting numbers you later have to cut and torch your reputation with the researcher community. Both fears are valid. Only one of them is solved by cutting bounties.

HackerOne cut bug bounty rewards by up to 89% on work researchers had already done

In May 2026, HackerOne reduced the Internet Bug Bounty’s reward tiers by roughly 76% to 89% across the board, then paused the program while it evaluated further adjustments. The IBB is the pooled fund that pays out for vulnerabilities in core open-source dependencies, and it had distributed more than $1.5M since 2012 with an 80/20 split between discovery and remediation support (source: InfoWorld / CSO).

The numbers

The cuts were not trims. Here is the old-versus-new tier table as of May 18, 2026:

Source: The Register, 21 May 2026. A medium-severity finding that used to be worth nearly two thousand dollars now pays under three hundred. HackerOne’s framing is that the IBB is “a unique, dynamic program where bounty levels automatically adjust based on the contributions from active participating sponsors.” On the AI cause, the company said “AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed. The balance between findings and remediation capacity in open source has substantively shifted.”

Why it is a trust story, not a budget story

A program is allowed to run out of money. A program is allowed to decide a tier was overpriced. What researchers reacted to was the change applying to work that was already finished. As security researcher Jakub Ciolek put it, “The trust issue here is that the change was effectively applied long after the work was already done, fixed, and publicly credited under a different expectation” (source: The Register).

One researcher received a $297 payout against a much higher prior expectation. Ciolek himself was still awaiting payment for Argo CD vulnerabilities reported in fall 2025 when the new tiers landed. His diagnosis of the broader moment is the thesis of this entire article: “The reduced payout is a symptom. The economics of vulnerability reporting are changing very quickly.” The lesson is not stop paying. It is change the rules forward, not backward.

The real pressure: AI didn’t lower bug quality, it raised report volume

The honest reading of 2026 is that the AI-slop pressure is real and documented, but the durable problem is volume, not AI per se. Programs are not drowning because AI writes bad bugs. They are drowning because AI writes many reports, and disproving a plausible-but-fake one still costs a senior engineer real time.

curl’s whiplash: kill the program, then bring it back

curl is the cleanest documented case, and it cuts both ways. Maintainer Daniel Stenberg shut the program down effective February 2026, saying “The current torrent of submissions put a high load on the curl security team and this is an attempt to reduce the noise” (source: The Register, 21 Jan 2026). For years, AI-assisted submissions to curl had discovered essentially nothing genuine during the slop era.

Then the trend flipped. By March 2026, curl returned to HackerOne because AI report quality had improved to the point where “almost all” of its now-good reports were AI-assisted, even though raw volume had roughly doubled year over year (source: The New Stack). The takeaway: AI is not permanently the enemy of report quality. The permanent change is volume. Your reward structure has to survive a high-volume inbox without punishing the researchers producing real bugs.

GitHub’s quieter move: swag instead of cash for low-impact bugs

On May 15, 2026, GitHub announced that low-impact-but-valid findings would get recognition instead of a payout: “Submissions that don’t demonstrate significant security impact but do result in a code or documentation fix will be recognized with GitHub swag rather than a bounty payout.” The rationale was explicit: “We’d rather see researchers invest their time in deeper, high-impact research and be compensated accordingly than optimize for volume on low-risk findings” (source: GitHub Blog).

That is the same economic instinct as the IBB cut: reserve cash for impact, dampen the volume incentive. But it landed very differently, and the difference is the whole game.

What “good” looks like: the difference between GitHub and the IBB

The constructive move and the controversial one are mechanically similar. Both reduce what low-impact work earns. The split is timing and notice.

GitHub changed the rules going forward and published the rationale before anyone submitted under the new terms. A researcher who files today knows that a documentation-fix-grade finding earns swag, not cash, and they opt in with that knowledge. The IBB cut hit work already submitted and credited under the old numbers. Same direction, opposite trust outcome.

This is not a new lesson. Back in 2020, Bountysource announced it would “retain” unclaimed bounties via a quiet terms-of-service change, reversed it after backlash, and watched projects like elementary OS publish posts titled “Goodbye, Bountysource.” Retroactive changes to a reward agreement are the archetypal trust-destruction move. The crypto bug bounty platform Immunefi crystallized the counter-principle in a piece titled “The Bug Bounty Program Is Law”: the published program page is binding, and a project cannot retroactively renegotiate a report that was already submitted under it.

The expectation at submission must equal the expectation at payout. Everything else is negotiable. That one is not.

So the framework below is not really about numbers. It is about making your published terms structurally unable to betray a researcher after the fact.

How to set bug bounty reward tiers that survive AI slop

Set tiers in four steps: anchor them to data, publish and lock them, make every payout auditable, and reward effort with recognition rather than a stealth pay cut. None of these requires a HackerOne-scale budget. They require discipline, and they are what separate a program researchers trust from the next cautionary headline.

Step 1: Anchor tiers to data, not vibes

Start by mapping severities to a scoring model so “critical” means the same thing every time. CVSS is the common choice; a context-specific model works if your assets do not fit CVSS cleanly. Then price each tier off real distribution data rather than a round number you guessed.

Two anchors matter:

• External benchmarks, especially when you are new. Microsoft’s published reward tables run $500 to $30,000 for applications and on-prem, and $1,250 to $19,500 for M365, with a record $17M paid in 2024 to 2025 (source: MSRC). Across HackerOne, the average yearly payout per active program is roughly $42,000, and the platform paid $81M total over the trailing year, up 13% (source: BleepingComputer). A common industry rule of thumb is that organizations are willing to pay north of $7,000 for a critical vulnerability, with no universal standard.
• Your own history, once you have any. The median, mean, min, and max you have actually paid per severity tier and per vulnerability type tell you where the real distribution sits, so you can price the next tier off evidence instead of slashing across the board.

Use ranged tiers (a min and a max per severity), not a single brittle number. Ranges let you reward an exceptional critical at the top of the band and a marginal one at the bottom without rewriting the table. That is the practice both Intigriti and the Bug Bounty Community of Interest recommend, and it is exactly what across-the-board cuts like the IBB’s lack.

Step 2: Publish and lock your terms and scope

Write the bounty matrix, the in-scope and out-of-scope assets, the excluded vulnerability types, your SLA commitments, and your safe-harbor language into a single published policy. Then version it, and treat the version a researcher agreed to at submission as binding for that report.

This is the structural answer to the IBB complaint. If the terms are published and locked at submission time, there is no mechanism by which finished work gets silently repriced. The researcher opts in to a known deal. If you want to change the deal, you change it for future submissions and you announce it, GitHub-style.

Step 3: Make every payout auditable

Every reward and every adjustment should be an explicit, logged, defensible event with a timestamp and a reason. An auditable ledger does two things. It proves to a researcher that the amount they received maps to the tier they were promised. And on the rare occasion you genuinely do adjust a reward, it shows the adjustment was a deliberate, recorded decision rather than an opaque automatic re-rate.

The IBB’s “bounty levels automatically adjust” framing is precisely the thing a ledger prevents. Automatic and invisible is what erodes trust. Deliberate and logged is what preserves it, even when the number changes.

Step 4: Reward effort with recognition, not a stealth pay cut

Low-impact-but-valid findings deserve acknowledgment. The right way to give it is a separate, additive recognition lane: reputation or karma points, swag, a hall-of-fame listing. The wrong way is dressing up a cash reduction as “recognition” on work that should have been paid.

GitHub’s swag-for-low-impact policy is the clean version because it is announced in advance and runs alongside cash for high-impact bugs, never replacing promised cash on already-submitted work. Recognition is a complement to your locked cash tiers. It is never a backdoor for repricing.

Doing this in Kit

Kit’s CSIRT toolset is built around exactly these four habits, which is the point: the discipline is enforced by the tooling, not left to good intentions. To be clear, Kit is a young program-management product, not a marketplace with HackerOne’s payout volume or benchmark dataset. The differentiator is the structure it imposes, and that structure is most of what trust comes down to.

• Benchmark-anchored tiers. Aggregate your own historical awards (median, mean, min, max, recent examples) filtered by severity tier and vulnerability type, so you price each tier off real distribution data and can show a researcher the median for their bug class. New programs lead with external benchmarks, like Microsoft’s published bands, until they have history of their own.
• Ranged, published tiers. Configure the bounty matrix as min and max per severity across informational, low, medium, high, critical, and a super-critical tier, then publish it alongside scope, SLA, and safe-harbor terms as a versioned policy researchers agree to at submission.
• An auditable ledger. Every approval, adjustment, and disbursement is a typed, logged financial event filterable by report and date, so the payout maps to the promise and any adjustment is a recorded decision, not a silent re-rate.
• A separate karma lane. Non-cash recognition rides alongside the locked cash tiers with fixed, transparent presets, so a valid-but-low-impact finding gets honored without anyone disguising a cash cut as a thank-you.

We went deep on keeping a program alive when the inbox floods in the VDP triage playbook, and on standing one up from zero in how to set up a vulnerability disclosure program. This article is the reward-design layer on top of both.

FAQ

Can a bug bounty program change rewards after submission?

It can, but it should not. The IBB backlash in May 2026 was driven less by the size of the cut than by the fact that it applied to work already submitted, fixed, and credited under the old tiers. The defensible pattern, modeled by GitHub, is to change rewards going forward only, with published notice, so researchers opt in to the new terms knowingly. Treat your published program page as binding for any report submitted under it.

How much should I pay for a critical bug bounty?

There is no universal standard; it is a risk calculation. As directional anchors, Microsoft pays up to $30,000 for top-tier application findings, the average HackerOne program pays around $42,000 per year across all tiers, and a common rule of thumb has organizations paying north of $7,000 for a critical (sources: MSRC; BleepingComputer). Set a min-max range per severity anchored to those benchmarks and your own history, not a single fixed number.

How do I handle AI-generated bug bounty reports?

Do not cut bounties to discourage them; that punishes the researchers producing real bugs. The durable problem is volume, not AI. curl proved AI report quality can flip from worthless to “almost all good” within a year. Handle volume with triage (filtering, rate limiting, reputation scoring, SLA protection) and handle reward design by paying for impact and recognizing low-impact work separately, so the incentive rewards quality over submission count.

The bottom line

When AI floods your inbox, the instinct is to protect the budget by cutting what you pay. The IBB shows where that goes when the cut hits finished work: a credibility hole that no amount of money refills quickly. The durable answer is structural. Benchmark your tiers off real data, publish and lock the terms and scope, log every payout so adjustments are deliberate and visible, and reward effort with recognition that sits alongside cash rather than replacing it. Do that and your VDP stays credible when the AI flood hits, instead of becoming the next cautionary headline.

If you are designing a reward matrix you want to publish today and not regret in six months, start a free Kit trial and configure a benchmarked, locked, auditable program from the start.