AMD Patches Critical Auto-Updater RCE in 124 Days, Then Denies the Researcher His $10,000 Bounty

AMD has shipped a fix for a remote code execution vulnerability in its driver auto-updater, closing the hole 124 days after a researcher named Paul first reported it. The company declined to pay him the $10,000 his finding would otherwise have commanded, citing a policy carve-out for man-in-the-middle attacks. The disclosure timeline, the nature of the fix, and a final twist about whether the bug was even reachable together make this one of the messier coordinated-disclosure episodes of the year.

What the bug actually was

The vulnerability lived in the download routine of AMD's updater software, the component that pulls fresh driver packages and tools like Ryzen Master. The updater fetched its payloads over plain HTTP rather than HTTPS. That single detail is the whole exploit chain. An attacker positioned between the victim and AMD's servers, on a shared coffee-shop network, a compromised router, or via DNS poisoning, could intercept the unencrypted request and substitute a malicious binary. Because the updater then executes what it downloads with the privileges of an installer, the result is remote code execution on the target machine.

MITM-delivered RCE is not exotic. It is the textbook reason transport encryption exists. The fix, as Paul characterized it, was effectively a one-character change: replacing http with https in the relevant URL. AMD's bug bounty program rates an RCE-class finding at up to $10,000. The catch is that the program's policy explicitly excludes vulnerabilities that depend on a man-in-the-middle position, and AMD used that clause to reject the report outright.

A 124-day clock that kept resetting

The disclosure history is where the story turns. Paul submitted the report, AMD declined the payout, and in February the company asked him to take down a blog post describing the issue while it prepared a coordinated fix. AMD agreed to issue a standard CVE and to credit him, but held firm on no bounty. Paul agreed, a decision he now says he regrets, and proposed the industry-standard 90-day disclosure window.

AMD countered that it would need longer, explaining that tools beyond Ryzen Master were affected and would need their own releases. The parties settled on a 100-day embargo. As that deadline approached, AMD asked for still more time, again citing multiple affected tools and noting that its customers request additional lead time once fixes become available. The patch finally landed on June 9, putting the total at 124 days from initial report to remediation.

That timeline invites obvious questions. If the core fix was swapping a protocol prefix, why did it take four months? And if the issue was serious enough to warrant repeated embargo extensions and a coordinated rollout across multiple tools, why did it not warrant either a higher internal priority or some form of compensation for the person who found it? The two positions sit uncomfortably together: the bug was minor enough to deny a bounty but severe enough to need 124 days of careful, multi-product release engineering.

The fix is real, but the hashing is dated

To AMD's credit, the company did not patch in the most minimal way possible. Paul verified that AMD reengineered the download code in the auto-updater and that the new version pulls drivers over a secure channel as intended. The transport problem appears genuinely closed.

The integrity-checking story is weaker. Paul notes that the updater still validates downloaded files using CRC32, a 32-bit checksum designed in the 1970s for detecting accidental transmission errors, not for resisting deliberate tampering. CRC32 is not a cryptographic hash. Collisions are trivial to construct, and an attacker who can manipulate file contents can forge a matching checksum without effort. For a software updater, the correct primitives are a SHA-256 (or stronger) digest combined with a signed manifest or code-signing verification, so the client can confirm both that the file is intact and that it came from AMD. Relying on CRC32 for what is functionally a security check leaves a gap, even if HTTPS now does most of the heavy lifting.

The part that makes it absurd

A final wrinkle came from a Reddit user who pointed out that the vulnerable code path may not have been reachable in the first place. The section containing the insecure download logic was apparently not being invoked, meaning the updater was effectively broken and could not update itself through the normal mechanism. The practical consequence is that AMD could not simply push the patched updater through the updater. Users have to grab a fresh copy of the software pack by hand to get the fixed version.

An auto-updater that cannot update itself, shipping a fix for a bug in code that was not running, is the kind of recursion that writes its own punchline. Paul rendered it in mock-Latin as Quis renovatores renovat — who updates the updaters.

Why this matters beyond AMD

The broader pattern is the friction between vendor bounty policies and the people who do the unpaid reconnaissance those policies depend on. MITM exclusions are common across bug bounty programs because the threat model assumes a privileged network position, but that assumption is increasingly weak in a world of public Wi-Fi, hostile networks, and compromised home routers. An RCE is an RCE regardless of the delivery vector, and an updater that runs code with installer privileges is exactly the kind of high-value target where transport security is non-negotiable.

Researchers watching this episode, alongside parallel disputes such as Microsoft's handling of the Nightmare-Eclipse reports, draw a consistent lesson: agreeing to pull a public post in exchange for a CVE and credit hands the vendor control of the clock with little leverage in return. Paul cooperated, accepted no payment, and absorbed four months of moving deadlines for a fix that arrived in code that may never have executed. The vulnerability is closed, which is the outcome that matters most for AMD's users. Whether the disclosure process that got there will encourage the next researcher to come forward is a separate question, and not one the bounty denial answers well.

AMD users should update to the latest version of the company's software pack manually rather than waiting for the auto-updater to deliver it, since the broken update path means the fix will not arrive on its own.