Key Takeaways
- AMD refused to pay a $10,000 bounty for a reported remote‑code‑execution (RCE) vulnerability, citing that man‑in‑the‑middle (MITM) attacks fall outside its bug‑bounty scope.
- The researcher, Paul, complied with AMD’s request to remove his public blog post in exchange for a promised fix, CVE assignment, and attribution—but no monetary reward.
- Despite multiple deadline extensions, AMD took 124 days to release a patched updater, during which Paul repeatedly asked for clarification and received only vague assurances.
- The eventual fix replaced “http” with “https” in the updater code and re‑engineered the download mechanism, but the integrity check still relies on the outdated CRC32 hash.
- Subsequent analysis suggested the vulnerable code path was never executed, rendering the updater effectively broken until a fresh user‑initiated download was performed.
- The case highlights a growing trend where vendors acknowledge severe bugs yet avoid bounty payouts by invoking policy loopholes or delayed disclosure timelines.
Background of the Disclosure
In February, security researcher Paul identified a potential remote‑code‑execution flaw in AMD’s auto‑updater software that could be exploited via a man‑in‑the‑middle attack. He submitted the finding through AMD’s bug‑bounty portal, anticipating both a patch and the standard $10,000 reward reserved for RCE‑class bugs. AMD’s initial response rejected the bounty, stating that MITM attacks were not covered by the program’s policy, even though the vulnerability’s impact merited an RCE classification. Paul was asked to temporarily take down his blog post describing the issue, with the promise that AMD would issue a CVE, fix the software, and credit him publicly—though no payment would be made.
Negotiating the Disclosure Timeline
Paul agreed to the takedown but sought clarity on when he could resume public discussion. He proposed adhering to the industry‑standard 90‑day embargo before re‑publishing his findings. AMD replied that it would likely need a longer embargo because “additional tools beyond Ryzen Master appear[ed] to be impacted and [would] need releases.” This raised questions: why a seemingly simple one‑character code change (replacing “http” with “https”) would require months, and why the issue did not receive higher internal priority if it truly warranted such a delay. After further back‑and‑forth, Paul conceded to a 100‑day window, only to be asked for yet more time later, with AMD citing that “multiple tools are affected by [the bug]” and that customers requested additional time once fixes were made available.
The Extended Fix Process
Ultimately, AMD informed Paul that a fix would be ready on June 9—124 days after the initial disclosure. During this period, the researcher received no financial compensation and only intermittent updates. When the patched version finally arrived, AMD had re‑engineered the download code in the auto‑updater altogether, replacing the insecure HTTP fetches with HTTPS and reportedly securing the update pipeline. Paul verified that the new build downloaded drivers over a secure channel, confirming that the network‑level MITM vector had been closed.
Remaining Weaknesses in the Updater
Despite the transport‑layer fix, Paul noted that the updater still validates downloaded files using a CRC32 checksum—a non‑cryptographic hash that is trivial to forge. While the switch to HTTPS prevents an attacker from intercepting and altering traffic, a determined adversary who could replace the file on AMD’s servers (or compromise a mirror) could still slip a malicious payload past the integrity check. This oversight means the updater is not fully hardened against supply‑chain tampering, leaving a residual risk that outweighs the original MITM concern.
Irony of the Vulnerability’s Exposure
Adding a layer of irony, a Reddit user later pointed out that the vulnerable code path Paul identified was never actually invoked during normal updater operation. Consequently, the auto‑updater was effectively broken: it could not retrieve updates because the routine responsible for fetching the new code was dormant. Users had to manually download a fresh installer from AMD’s website to obtain the patched version, meaning the very mechanism meant to keep systems secure was non‑functional until user intervention occurred. The Latin‑flavored quip “quis renovatores renovat?” (who updates the updater?) aptly captures the situation.
Industry Context and Recurring Patterns
Paul’s experience mirrors other high‑profile cases where large vendors acknowledge severe bugs yet avoid bounty payouts by citing policy limitations or extending disclosure timelines. Microsoft’s handling of the “Nightmare‑Eclipse” vulnerabilities, for example, followed a similar trajectory: researchers reported critical flaws, received acknowledgment and fixes, but were denied monetary rewards due to narrowly scoped bounty programs. Such outcomes can discourage responsible disclosure, push researchers toward full public exposure, or lead them to disengage from vendor‑run bounty schemes altogether.
Conclusion and Lessons Learned
The episode underscores the need for bug‑bounty programs to clearly define scope, especially regarding network‑based attacks like MITM, and to align reward structures with the severity of the findings rather than technicalities of attack vectors. Vendors should also prioritize timely fixes and transparent communication, ensuring that researchers feel their contributions are genuinely valued. Finally, while securing the transport layer is a vital step, comprehensive integrity verification—using modern cryptographic signatures—remains essential to defend against supply‑chain threats. Only by addressing both the immediate vulnerability and the underlying verification weaknesses can vendors like AMD truly protect their users and maintain trust with the security research community.