AMD Took 124 Days to Add an 's' to a URL: Inside a Disclosure Gone Sideways

A researcher who goes by MrBruh bought a new gaming PC and kept getting interrupted by a console window flickering open on his desktop. Annoyed, he traced it to AMD's AutoUpdate software, decompiled the executable to understand what it was doing, and stumbled into a remote code execution vulnerability that should never have shipped. What followed is less a story about a single bug and more a case study in how vendor security programs treat the people who find their problems.

The bug itself

The vulnerability is almost embarrassingly simple. AMD's updater stores its update URL inside the program's app.config file. That URL uses HTTPS, so far so good. The problem appears the moment you open the referenced XML file in a browser: every executable download link inside it uses plain HTTP.

That single detail is the whole vulnerability. An attacker on the same network, a compromised router, or anyone with access at the ISP level can intercept the HTTP response and swap the legitimate AMD executable for something malicious. The only thing standing between a user and arbitrary code execution would be signature validation on the downloaded file. There is none. The decompiled code shows the updater downloading the file and running it immediately, no certificate checks, no signature verification.

For a piece of software that ships on millions of machines and runs with the privileges needed to install drivers, that is about as direct a path to compromise as you can find. No memory corruption, no exotic exploit chain, just a man-in-the-middle and a replaced binary.

Out of scope, then suddenly in scope

MrBruh reported it. AMD runs initial triage through Intigriti, a third-party bug bounty platform, and the report was closed the same day it was filed. The reason: man-in-the-middle attacks fall outside the program's terms. He published a write-up describing the issue.

Then it hit the front page of Hacker News, and AMD's posture changed within 24 hours. The company's internal PSIRT (Product Security Incident Response Team) reached out, explaining that even though Intigriti had rejected the submission, they were still happy to review the details for potential validity.

The review concluded with three decisions: AMD would issue a CVE, implement a fix, and provide security researcher recognition. What it would not do is pay anything, on the grounds that the flaw affects an optional tool and depends on a MITM scenario. That same out-of-scope classification that killed the bounty did not, apparently, stop AMD from also asking MrBruh to take his blog post down because publishing it violated the program's terms. A report cannot be both outside the rules and bound by them, but that is the position the researcher was placed in. He agreed to pull the post, a decision he now says was the wrong call.

The embargo that kept growing

The industry norm for disclosure is 90 days, sometimes 90 plus a 30-day grace period. MrBruh's own review of past AMD advisories confirmed the company usually shipped fixes inside that window. So he asked what timeline they intended to follow.

The answer was vague and kept getting vaguer. AMD said it would likely need a longer embargo because tools beyond Ryzen Master were affected and would need their own releases. Updates that were promised did not arrive. The researcher only learned what the actual fix was a couple of days before the embargo ended, and only because he asked directly.

He waited an additional 69 days, reaching 87 days from initial disclosure, before telling AMD he would publish at the 100-day mark regardless. AMD asked for still more time, citing customers who needed to review fixes once released. Eventually the company committed to a June 9th disclosure date and said it had asked engineering to expedite. The final write-up went public 124 days after the vulnerability was first reported.

The punchline the researcher keeps returning to: the core fix is adding a single s to HTTP URLs in a hosted XML file. If the flaw were truly severe enough to justify a four-month embargo, the urgency should have cut the other way.

The bug that breaks the bug

There is a second twist that makes the whole thing stranger. According to a link surfaced in the Hacker News thread, the AutoUpdater is already broken for an unrelated reason. AMD migrated its package listings from ati.com to drivers.amd.com. A browser follows the redirect automatically, but the updater cannot handle the redirection and crashes or hangs before it ever reaches the vulnerable download code.

The result is an accidental Catch-22. The vulnerability is not currently exploitable because the updater dies before getting that far, and you cannot fix the updater through itself because the updater will not run. AMD users are better off uninstalling everything and pulling fresh versions directly from the AMD drivers site.

The patch that overpromises

AMD's final message described the fix this way: in Ryzen Master, the auto-updater was removed from the installer and moved into the application layer, all update communication now uses HTTPS, and updates undergo signature verification.

MrBruh validated those claims. The HTTPS part checks out. The signature verification part does not. What AMD actually implemented is a CRC-32 check on the downloaded executable. CRC-32 is an error-detection checksum, not a cryptographic signature. It tells you whether a file got corrupted in transit. It does nothing to stop an attacker who can simply compute a matching checksum for their malicious payload. Calling that signature verification is, at best, a generous description.

The economics of finding bugs nobody pays for

The most uncomfortable part of the write-up is the accounting. MrBruh reports finding and disclosing vulnerabilities to Google, ASUS, AMD, TP-Link, MSI, and others, with a combined payout of $0. By his estimate, the AMD bug would have been worth roughly $10,000 had it been ruled in scope. The current state of the disclosure is a CVE and a credit line.

That gap matters beyond one researcher's coffee fund. Bug bounty programs exist to route vulnerability discoveries toward defenders instead of the underground market. When the scope rules let a vendor accept a genuine RCE report, act on it, issue a CVE, request an extended embargo, and pay nothing, the incentive structure starts to wobble. The researcher did everything the responsible-disclosure playbook asks for, including pulling his post on request, and the reward was four months of intermittent communication and a checksum masquerading as a signature check.

The full timeline and decompilation walkthrough live on MrBruh's blog, and if the work was useful to you, he takes KoFi donations since the vendors did not. For anyone running AMD's optional tooling, the practical takeaway is unchanged: uninstall it and reinstall current builds from AMD directly. The interesting takeaway, for everyone else, is what this says about the distance between how vendors describe their security processes and how those processes actually treat the people feeding them.