Bug Bounty Payout Disputes: SLAs and Fairness in Your VDP

Bug bounty payout disputes happen when a program denies, reduces, or delays a reward without anchoring the decision to a rule the researcher could read in advance. The most common triggers are a slow fix with no resolution clock, an “out of scope” call made after the patch ships, a payout below the advertised matrix, and retroactive changes to the program terms. The fix is not paying more. It is publishing the clock and the matrix up front, tracking time-to-fix against them, and recording every approve, reduce, or decline decision in an auditable ledger.

In June 2026, AMD turned a cooperative researcher into a public critic by getting all four of those wrong at once. This is the playbook for not repeating it.

124 days, then “out of scope”: the AMD bounty fight

In February 2026, researcher Paul LaRosa (handle “MrBruh”) reported a high-severity flaw in AMD’s auto-updater tooling. The updater fetched its update list over HTTPS but pulled the actual executables over plain HTTP with no real signature check. An attacker on the same network could perform a man-in-the-middle attack and push malicious code to the victim’s machine.

AMD took 124 days to ship a fix. Then it denied the $10,000 bounty, calling man-in-the-middle attacks against “optional tools” out of scope. This happened despite AMD assigning a CVE (CVE-2026-40677, CVSS 4.0 base score 7.7, HIGH) and publicly crediting LaRosa in its own security bulletin. The eventual patch added only a CRC32 check, which is an integrity checksum, not a cryptographic signature. Multiple outlets also reported that AMD revised its program terms to require written consent before disclosure, then applied that change to LaRosa’s case after the fact.

The bug was not the story. The story is that a slow clock plus an opaque, after-the-fact payout decision converted a researcher who quietly reported a real flaw into someone with a megaphone and a grievance. Every part of that outcome was a process choice, and every part was avoidable.

This article does not determine AMD’s legal obligations to the researcher. It examines communication about scope, timing, and reward decisions.

Why bug bounty payout disputes happen

Bug bounty payout disputes are rarely about the dollar amount alone. They come from the gap between what a program advertised and what it actually did. Researchers tolerate a low ceiling; they do not tolerate a moved goalpost. Five trust-killers cause most disputes:

• No resolution clock. The fix drifts for months because nothing is counting down. The researcher sits in silence and assumes bad faith.
• “Out of scope,” decided after the fix ships. Eligibility is ruled on retroactively, once the company already has the patch in hand.
• Paying below the advertised matrix. A program promising “$1,000+ for Medium” pays $200 with no explanation, so the felt injustice is the gap, not the number.
• Retroactive rule changes. Terms shift mid-report, and the new terms get applied backward to a report filed under the old ones.
• Opaque, unrecorded decisions. Nobody can reconstruct who decided what, when, or against which rule.

Security veterans have warned about this for years. As critics including Katie Moussouris, Jonathan Leitschuh, Robert Graham, and Tavis Ormandy have argued in coverage of the bug bounty industry, NDAs and silence-buying erode the disclosure model; transparency is what makes a program effective. The pattern in every dispute is the same: the decision was not anchored to anything the researcher could have read in advance.

No resolution clock means the fix just drifts

A vulnerability with no remediation deadline is a vulnerability nobody owns. Most organizations take 60 to 150 days to patch critical vulnerabilities, according to remediation-SLA research from Secure.com. Meanwhile, attackers exploit critical flaws in as little as 5 days after public disclosure, and roughly 60% of 2024 breaches were tied to a known, unpatched vulnerability. AMD’s 124 days sat squarely inside the danger zone, and because no clock was published, no one was accountable for it.

“Out of scope,” decided after the fix ships

Scope is a promise you make before the report arrives, not a verdict you reach after you have the patch. When a program accepts a report, assigns a CVE, credits the researcher, then declares the same issue out of scope, the scope decision reads as a payment-avoidance maneuver, because functionally that is what it is. Decide eligibility against a pre-published scope document or do not invoke scope at all.

Paying below the advertised matrix

A separate, widely discussed dispute involved a researcher offered $50,000 for a critical bug against a program’s stated $500,000 maximum, with no detailed explanation for the reduction and a long payment delay. The amount may have been defensible. The silence was not. A reduction without a documented reason against a public matrix always looks like a lowball, even when it isn’t.

Retroactive rule changes

Changing your program terms is fine. Applying the new terms to reports filed under the old ones is not. Once you accept a submission, the rules in force at submission time are the rules that govern it. Everything else is a bait-and-switch, and the research community treats it as one.

How fast is “fast enough”? Resolution SLAs by severity

A resolution SLA is a published, per-severity deadline for shipping a fix, measured from the moment you confirm the report. It is what makes “124 days” objectively indefensible instead of a matter of opinion. Widely cited industry targets are tight:

Sources: Secure.com remediation-SLA guide; GitLab vulnerability-management handbook.

Against any of these benchmarks, a 124-day fix for the High-severity issue is multiples over target. The exact tier boundaries are yours to set. What matters is that you set them, publish them worst-first on your policy page, and put a clock on every confirmed report so “overdue” is a status the system surfaces, not a complaint the researcher has to file.

What a bounty should actually pay

A bounty matrix is a published table of reward ranges per severity tier, anchored to real market data so awards are calculated, not negotiated away. Public benchmarks give you the anchors:

Sources: bug-bounties.as93.net (HackerOne medians); Bugcrowd payout guidance.

These are ranges, not gospel. Google’s Vulnerability Reward Program pays far higher, with critical findings landing between $10,000 and $31,337, and platform-wide HackerOne paid researchers roughly $81 million over a recent 12-month span. Present your matrix as ranges, attribute the platform you benchmarked against, and resist quoting a single canonical “average bounty.” The point of the matrix is not to be generous. It is to make a researcher able to estimate their reward before they hit submit, and to make your eventual award land inside a band they already saw.

How to decline a report without losing the researcher

You will decline reports. Out of scope, duplicate, informational, accepted-risk: all legitimate. A decline only becomes a dispute when it is a surprise. Four practices keep a “no” from becoming a public fight:

1. Decide against a pre-published rule. Point to the scope document or matrix tier the decision rests on, by name. If the rule did not exist when the report was filed, you cannot use it.
2. Show the data. When you reduce an award, show the benchmark band the number came from. A documented reason beats a generous number paid in silence.
3. Keep recognition intact. A declined payout does not have to mean erased credit. Hall-of-fame placement and reputation points cost nothing and preserve goodwill even when money is contested.
4. Offer an appeal. A one-way “no” reads as final-by-fiat. A reviewable decision reads as fair, even when the answer doesn’t change.

If you have not yet stood up the intake side of this, start with our guide on how to set up a vulnerability disclosure program. And if your worry is the relationship rather than the money, the companion piece on when researchers go public after a botched disclosure covers the trust mechanics in depth. This article is the day-2 sequel: how not to lose a researcher when money and a deadline are both on the line. (For the rising volume problem, see AI slop flooding bug bounty triage.)

Deadlines, rewards, and appeals in Kit

The CSIRT module keeps report handling and reward records together:

• Acknowledgment and resolution SLAs. Targets and their status are visible on reports.
• Scope and reward tiers. The program publishes rules; the team still assesses whether a particular report qualifies.
• Reward history. Statistics describe your own payouts, not the market value of every vulnerability.
• Financial records. Reward and settlement entries help trace payments. They do not replace the technical rationale.
• Appeals. Researchers can submit a justification for another review, subject to the program’s appeal limit. The team records the outcome. Accepting an appeal does not automatically increase a reward.
• Recognition. Karma and the Hall of Fame record contributions under the program’s rules.

Publish scope, deadlines, and reward criteria before accepting reports. Explain each decision with the applicable rule and the facts of the case. The record helps review a dispute; it does not guarantee agreement.

Start a free trial to prepare a program and try handling a report in Kit’s CSIRT module.