A security researcher says AMD fixed a flaw in its Windows auto-updater after a months-long disclosure process, but did not pay the reported $10,000 bug bounty the researcher believed should apply to the issue.
The case centers on an AMD auto-updater vulnerability described by a researcher identified as Paul. According to the researcher’s account, the updater could retrieve driver packages over an insecure connection, creating a possible man-in-the-middle attack path if an attacker could interfere with network traffic. The concern was not simply a broken download flow: the researcher argued that a tampered update could become a route to remote code execution because driver installation workflows often run with elevated privileges.
The core facts remain partly dependent on the researcher’s published account rather than a full public statement from AMD. That matters. The safest reading is that AMD addressed the updater behavior after disclosure, while the bounty decision and the exact internal reasoning behind it have not been independently confirmed in detail.
What the researcher reported
Paul’s account says the issue was submitted through AMD’s vulnerability reporting process, with the expectation that a remote-code-execution-class weakness would qualify for a payout. The report was reportedly rejected for bounty purposes because man-in-the-middle attacks were outside the program’s covered scope.
That distinction is the heart of the dispute. From a narrow policy view, a vendor may exclude some network-position attacks from bounty eligibility. From a user-risk view, an updater that can be influenced into downloading untrusted code is still a serious software supply-chain security concern.
After the initial disclosure, the researcher said AMD asked for the public blog post to be taken down temporarily while the company worked on a fix. The researcher agreed, while also asking for a disclosure timeline. The source account says AMD indicated that more than one tool might be affected, which made the fix process broader than a single updater component.
The researcher originally suggested a 90-day disclosure window, a common benchmark in vulnerability reporting. The final timeline described in the source article was longer: 124 days from the initial finding to the reported availability of a fix.
Why the patch timeline drew attention
The length of the process is notable because the reported flaw sounded simple at first glance: downloads that should have used HTTPS were said to be using HTTP. In practice, updater systems can be more complicated than a one-line change, especially if several applications share related download code or if the vendor needs to coordinate releases across separate tools.
Even so, the timeline created an uncomfortable contrast. If the issue was serious enough to require a coordinated, multi-tool repair, the researcher’s argument for recognition becomes easier to understand. If it was not serious enough to qualify for a bounty, the extended embargo looks harder to reconcile from the outside.
The source article says Paul later verified that AMD’s revised updater downloads drivers securely. It also notes his concern that the updated flow still relied on CRC32 for checking downloaded files. CRC32 can catch accidental corruption, but it is not treated as a modern cryptographic integrity check.
The bounty question remains unresolved
The public dispute is less about whether a fix happened and more about how vulnerability programs handle edge cases. Bug bounty rules often draw strict boundaries around what qualifies. Researchers, meanwhile, tend to judge a report by impact: whether an attacker could turn the behavior into code execution, credential theft, persistence, or another meaningful compromise.
In this case, the reported $10,000 figure appears tied to how AMD’s program would value a qualifying remote-code-execution issue. Because AMD reportedly treated the man-in-the-middle condition as out of scope, the researcher says the payout never arrived.
A separate claim circulated that the vulnerable updater path may not have been triggered because the relevant update code was not being called. That detail has not been firmly established in the public record, so it should be treated cautiously rather than as a settled explanation.
For AMD users, the practical point is narrower: the researcher’s account says the revised software package includes the updater-side fix. For security teams and bug bounty participants, the broader lesson is about scope language. When updater infrastructure, insecure transport, and elevated installation privileges overlap, a policy exclusion can become controversial even if the vendor believes it is applying the rules as written.