WELLINGTON — The pop-up kept appearing on Paul LaRosa’s new gaming PC. A console window, briefly visible, then gone. Annoying enough that the 22-year-old New Zealand programmer, who publishes security research under the name MrBruh, decided to find out what was causing it.
What he found was a flaw that could let any attacker positioned on the same network — a café, an airport, a corporate Wi-Fi — silently swap AMD’s software update with a malicious executable, then run it with elevated system privileges. The kind of attack that requires no user interaction and leaves no obvious trace.
AMD’s auto-updater fetched its update list over HTTPS, but the actual executable download links inside that list used plain HTTP. More critically, according to LaRosa’s own detailed writeup, the software performed no certificate validation and no cryptographic signature check before running whatever it downloaded. A man-in-the-middle attacker on the same network could replace the update file entirely.
LaRosa reported the issue to AMD on February 6 through the company’s bug bounty program, administered by the third-party platform Intigriti. AMD closed the report the same day. Man-in-the-middle attacks were out of scope. Optional tools were out of scope. No bounty. The vulnerability would eventually receive a CVSS 4.0 score of 7.7 and the designation CVE-2026-40677 — scores AMD assigned only after the researcher made the flaw public.
What followed was a sequence that security researchers are now describing as a case study in how bug bounty programs can be turned against the people they are supposed to reward.
After LaRosa published his findings on February 6 and the post gained traction on Hacker News, AMD’s internal Product Security Incident Response Team resurfaced. The company said the issue was still under internal review and asked him to take the post down, saying the disclosure appeared to violate the program’s terms. LaRosa agreed — a decision he later wrote he regretted.
AMD then told LaRosa it would issue a CVE, implement a fix, and give him researcher credit. What it would not do was pay the $10,000 the program listed as a potential award. The tools were optional, AMD said. The attack required a man-in-the-middle position. Neither condition prevented AMD from issuing a formal security bulletin — but both, in AMD’s accounting, disqualified the report from payment.
AMD then requested an extended embargo period, citing multiple affected software products requiring coordinated releases. The industry standard disclosure timeline is 90 days. LaRosa waited 87 days before informing AMD he intended to republish at the 100-day mark. AMD did not actively keep him updated despite assuring him it would, disclosing the nature of the patch only two days before the embargo ended — and only after LaRosa asked directly. The full process ran to 124 days, the embargo ending June 9.
Then came the detail that transformed a corporate dispute into something more troubling. TechSpot reported, citing an analysis by Gamers Nexus, that AMD altered the wording of its bug bounty rules after LaRosa had already published the flaw. The updated terms required researchers not to disclose vulnerability information without AMD’s written consent — even when a report was deemed out of scope or ineligible for a bounty. AMD then used those new rules to argue that LaRosa’s original February disclosure had violated the program’s terms.
The retroactive quality of that argument is the sharpest edge of the whole episode. When LaRosa published in February, no such confidentiality clause existed for out-of-scope reports. His disclosure was technically permitted under the rules as written. AMD appears to have identified that gap, updated its terms to close it, and then pointed to the newly closed gap as evidence of a violation that predated it.
AMD’s official security bulletin, AMD-SB-9027, now lists AMD Ryzen Master 2.14.3, AMD μProf 5.3, and AMD Management Console 14.0.0 as the mitigated versions. The company told LaRosa that all update communications now use HTTPS and that updates undergo signature verification. LaRosa confirmed the HTTPS claim is accurate. The signature verification claim, he found, is not: the software performs only a CRC-32 check on the downloaded executable. CRC-32 is a cyclic redundancy check designed to detect accidental data corruption. It is not a cryptographic signature and cannot reliably detect deliberate tampering by an attacker who knows the check will be applied.
There is also a separate bug — entirely unrelated to the one LaRosa discovered — that may have inadvertently contained the vulnerability for months before the patch arrived. AMD switched its software hosting from ati.com to drivers.amd.com at some point, but the auto-updater cannot handle the resulting redirect and crashes before reaching the vulnerable download code. The flaw LaRosa found may have been unexploitable in practice during the four months he spent waiting for AMD to patch it — not because AMD secured anything, but because the software was too broken to function. Fixing the redirect bug, he noted, could restore exploitability unless the patch is also correctly applied. His recommendation is unambiguous: AMD users should fully uninstall the company’s software suite and download the latest versions manually from AMD’s website, bypassing the auto-updater entirely.
The episode is attracting attention well beyond the specific vulnerability, which is relatively narrow in scope and requires a specific network position to exploit. The broader concern is what AMD’s conduct signals about the value large technology companies place on independent security researchers. The incentive structure, as researchers noted on Hacker News and elsewhere, now points the wrong direction: a researcher who finds a similar AMD flaw has rational grounds to exploit it privately or sell it to a broker, rather than report it through a program that may close the submission, suppress publication, change the rules after the fact, and still pay nothing.
AMD is not the only company navigating these tensions. A zero-day in Microsoft Exchange that was being actively exploited in the wild earlier this year raised similar questions about how institutions treat the researchers who surface critical flaws before malicious actors do. A maximum-severity flaw in Cisco’s Secure Workload platform, disclosed last month with a CVSS score of 10.0, also drew scrutiny over response timelines. What distinguishes the AMD case is the retroactive rule change — a maneuver that is harder for any researcher to accept, regardless of whether the underlying scope decision was reasonable.
AMD had not publicly addressed specific questions about the rule change or the CRC-32 dispute as of Friday. The company’s security bulletin credits LaRosa for the discovery. Whether that credit is adequate compensation for 124 days of embargo, a withheld $10,000 payment, and a retroactive confidentiality clause is a question AMD has already answered for itself. The security research community is now answering it for AMD in return — one disclosure at a time, and in a direction the company may not find favorable.
