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 critical 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.

A note on what this article does not claim: AMD was not legally obligated to pay, and nobody can force a given report into scope. The honest, narrower claim is that the process failed. A silent clock, an undocumented scope call, and an unledgered decision are what turned a denied bounty into a reputational incident.

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 a critical, RCE-class 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.)

How Kit operationalizes resolution SLAs and payout fairness

Kit’s CSIRT vertical was built as a near line-for-line answer to the AMD failure: publish the clock and the matrix, track time-to-fix against them, and record every payout decision so it is defensible instead of deniable. Here is how each AMD misstep maps to a built-in feature.

The thesis is narrow and it holds: AMD did not lose the researcher because the bug was hard. It lost him because no clock was running and the payout call was made in the dark, after the fact, against a rule that did not exist when he reported. A resolution SLA you publish and track, plus a bounty matrix anchored to your own payout data and recorded in a ledger, turn “out of scope, no payment” from a betrayal into a predictable, defensible decision. Whether you pay any given report is still your call. Kit makes that call fast, data-anchored, and auditable.

The takeaway: publish the clock and the matrix before you ever say no

Every bug bounty payout dispute traces back to the same root cause: a decision made against a rule the researcher never got to see. Publish your severity-tiered resolution SLAs. Anchor your bounty matrix to real benchmark data and publish it too. Put a clock on every confirmed report so “overdue” is a system state, not a researcher’s complaint. Record each approve, reduce, and decline in a ledger you can audit. Do that, and a decline becomes something a researcher expected, can verify, and will keep reporting around, instead of the thing that lands you on the front page of Tom’s Hardware.

If you run a VDP or paid bounty program and the money-and-clock side still lives in spreadsheets and goodwill, that is exactly the gap Kit’s CSIRT module closes. Start a free trial and set your SLAs and bounty matrix before the next critical report lands.