AMD has come under fire after a security researcher said the company refused to pay a promised $10,000 reward for a critical flaw in its automatic driver update system, even though AMD eventually patched the issue 124 days after it was reported. The case adds another awkward chapter to the company’s bug bounty story: the vulnerability was serious enough to trigger an RCE concern, but AMD reportedly decided the attack path fell outside its payout rules.

The researcher said the weakness could be used through a man-in-the-middle attack against AMD software. That is the sort of bug vendors love to describe as theoretical right up until someone shows how practical it is. Security programs often draw sharp lines around remote code execution, but those lines get messy fast once transport-layer tampering and update channels are involved.

How the AMD bug bounty report played out

According to the account, the researcher filed the issue through AMD’s vulnerability reward program and expected the standard payment for an RCE-class finding. AMD declined, arguing that man-in-the-middle scenarios are not covered by its payout policy. The company still fixed the bug, but not quickly: the correction took 124 days and went through repeated deadline changes before landing.

  • Reported issue: potential remote code execution via man-in-the-middle attack
  • Expected reward: $10,000
  • Fix time: 124 days

Bug bounty policies and the awkward fine print

That gap between ”we patched it” and ”we will pay for it” is where bug bounty programs tend to annoy everyone. Vendors want tight definitions to avoid open-ended payouts; researchers want compensation when a bug is real, dangerous, and confirmed in production code. If AMD’s policy excluded this class of attack, the company may be technically consistent, but consistency is not the same as good optics.

Cases like this also underline a broader industry pattern: update mechanisms are prized targets because they sit close to trust itself. When software used to deliver drivers can be nudged into doing the wrong thing, the security problem is bigger than a single crash or glitch – and that is exactly why researchers keep filing these reports, bounty or no bounty.

What AMD may face next

The immediate question is whether this dispute stays a one-off complaint or turns into a reputational tax on AMD’s reward program. Other hardware vendors have learned the hard way that refusing payouts for borderline cases can discourage future disclosures, especially when the fix arrives slowly and the researcher has already agreed to an embargo. Expect more scrutiny the next time AMD invites outside researchers to help clean up its software stack.

Source: Ixbt

Leave a comment

Your email address will not be published. Required fields are marked *