AMD has patched a software update flaw after 124 days, but the security researcher who found it says the company still refused to pay the $10,000 bounty he requested. The case is a neat reminder that vendor bug-bounty policies can be very specific, very stingy, and sometimes both at once.
The issue surfaced in February in AMD’s software update system and could have enabled a man-in-the-middle attack and remote code execution. AMD asked the researcher, Paul, to take down his blog post while it promised to assign a CVE, fix the software, and credit him publicly – just not with cash, because the company said the attack type did not qualify under its policy.
AMD’s patch arrived after a long delay
Paul initially pushed for a standard 90-day disclosure window, which AMD effectively stretched by saying it likely needed a longer embargo. The company argued that more than one tool was affected, not just Ryzen Master, and later asked for yet more time, saying customers wanted the update delay extended until after the fixes shipped.
That schedule looks awkward even before you get to the details. In a lot of software-security cases, a simple update-path fix is treated as a fast-moving operational problem, because leaving the update mechanism exposed is a bad look for any vendor that relies on trust to distribute patches in the first place.
What changed in AMD’s update mechanism
AMD says the updated package now protects against the attack, and Paul confirmed the driver download process now runs in a safer mode. The company also rewrote the auto-update download code, which is the kind of thing that sounds simple right up until multiple internal tools and update paths get involved.
- Reported in February
- Fixed on 9 June
- 124 days between discovery and patch
- $10,000 bounty denied
There is, however, one ugly footnote. Paul says the file integrity check still relies on CRC32, which is old enough to make modern cryptography people sigh into their keyboards. It may be better than nothing, but it is not exactly the sort of detail that screams ”trust us” from a company shipping security-sensitive software.
The awkward part AMD probably did not want public
The most entertaining wrinkle comes from Reddit, where one user claimed the vulnerable code path was never actually called, meaning the exploit would not have worked in the first place. If that is true, the whole episode becomes a rare software-security soap opera: the update system could not update because the update code was not being invoked, and users would have had to install the software manually anyway.
That is the kind of story that tends to haunt vendor security teams longer than the patch itself. AMD has now fixed the flaw, but the combination of a denied bounty, a stretched timeline, and a still-questionable integrity check leaves plenty of room for the next researcher to ask the obvious question: if this was so hard to patch, how many similar edges are still sitting in the toolkit?