After being interrupted multiple times by an annoying console window that would pop up periodically on my new gaming PC, I managed to track the offending executable down to AMD’s AutoUpdate software.

In my frustration, I decided to punish this software by decompiling it to figure out how it worked, and accidentally discovered a trivial Remote Code Execution (RCE) vulnerability in the process.

The first thing I found is that they store their update URL in the program’s app.config. Although it’s a little odd that they use their “Develpment” URL in production, it uses HTTPS, so it’s perfectly safe.

The real problem starts when you open up this .xml URL in your web browser, and realise that all the executable download URLs are using HTTP.

This means that a malicious attacker on your network, or a nation-state that has access to your ISP, can easily perform a MITM attack and replace the network response with any malicious executable of their choosing.

I was hoping that AMD perhaps had some form of certificate validation to ensure that it could not download and run any unsigned executables. However, a quick look into the decompiled code revealed that the AutoUpdate software does no such validation and immediately executes the downloaded file.

After finding this, I thought it would be worth reporting to AMD, as it seemed pretty severe.

Unfortunately, the terms of service of their bug bounty program state that man-in-the-middle attacks are out of scope, and it was closed as such.

UPDATE! Within a day of this blowing up on Hacker News, AMD reached back out to me and said they would be looking into the matter after all.

I am writing from AMD PSIRT. We are still conducting an internal review of your report. Please note that even if Intigriti has rejected the submission as out of scope for the bounty program, we are still happy to review the details to determine whether there may be any potential validity.     

Note: Intigriti is the third-party bug bounty platform AMD uses for initial triage, while PSIRT (Product Security Incident Response Team) is AMD’s internal security team.

Additionally, they requested I take down the blog post until they patched the issue.

We were informed that a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms. Could you please take the post down and wait for us to complete our review and provide an official response?  

I agreed to do so, which, in hindsight, I believe was the wrong choice to make.

The report was marked out of scope because it is not eligible for a bounty under our current program guidelines, as it affects optional tools and relies on a MITM attack scenario.  
  
After further internal review, we've decided to:  
  
- Issue a CVE for this vulnerability  
- Implement a fix  
- Provide you with security researcher recognition  

After agreeing to take down my blog until the vulnerability was patched, they followed up by detailing that they would not be paying me because it’s an optional tool and requires MITM, but instead they would be issuing a CVE for this and giving me credit.

What disclosure timeline you intend to follow?  
  
e.g 90 + 30 days  

I asked them what disclosure period they were planning to follow for this issue. The industry standard is 90 days, and after looking at other researchers’ write-ups, I can confirm the majority of AMD’s vulnerabilities were addressed within 90 days.

Hi @mrbruh, We will likely need a longer embargo, as additional tools beyond Ryzen Master appear to be impacted and will need releases. I’ll keep you updated as we learn more.  

So in summary, this is the current state of the disclosure:

• They declared it out of scope for a bounty, but requested that I take down the blog post because it was breaking the bug bounty’s rules.
• Not only did they ask me to take the blog post down, but they also asked me to keep it down for an extended duration compared to the industry standard.
• They justified this extended embargo period by saying that this issue might affect several of their software products; however, the patch itself could be as simple as adding a single s to an http URL in their hosted XML file (so it should be relatively easy to fix).
• Also, if this is such a big issue that millions of people’s computers could get hacked at any time from a number of AMD’s products, then it should be a priority to fix this quickly, no?

I ended up waiting an additional 69 days, for a total of 87 days from disclosure until I reached out again.

I told them that I could not continue to wait an indefinite amount of time for them to fix this issue, and that I planned to publish my write-up again at 100 days after initial disclosure had passed.

AMD did not actively keep me updated, despite assuring me they would. They only told me what the fix for this vulnerability was a couple of days before the embargo ended (and only after I explicitly asked).

Multiple optional tools are affected by this. We are awaiting release on at least one of them. Moreover, our customers request additional time to review fixes once they are made available. So we request you to hold public disclosure to give additional time for customers.  

They initially just asked for “more time”, without specifying a disclosure period, but two days later they agreed to end the embargo on June the 9th.

Hi @mrbruh, I have asked the engineering teams to expedite this so we can disclose it on June 9th. Will keep you updated.  

I am planning to publish this updated write-up, a total of 124 days after initial disclosure.

124 days to get AMD to add an s to a couple of HTTP URLs!

The Kicker

I don’t think it even matters what patch AMD has cooked up to fix this issue.

According to a link posted in the Hacker News thread of my original post, the auto updater is completely broken due to a second, entirely unrelated reason.

They switched from hosting their list of software packages on ati.com to drivers.amd.com at some point.

Opening the XML URL in your web browser will automatically redirect you to the new domain. However, the AutoUpdater program cannot handle this redirection, causing it to crash or lock up.

In some weird twist of events, I guess this means that the vulnerability I found actually isn’t exploitable because the AutoUpdater doesn’t even reach that section of code before completely shitting the bed.

It also results in a kind of Catch-22: you need to update the updater to fix the vulnerability, but the updater won’t update until the redirection bug is fixed. Nice.

If you are an AMD user with their software installed, I highly suggest fully uninstalling everything, then grabbing the new versions from their website.

Final update: A couple of days before the embargo ended (and after I wrote the majority of this blog post), AMD told me what their patch for this vulnerability is:

Hi @mrbruh In Ryzen Master, the auto-updater functionality has been removed from the installer and moved to the application layer. 

Within the application, all update communications are secured using HTTPS, and updates undergo signature verification.

I have since validated those claims. Although it is true that they now fully use HTTPS, the claim about signature verification is untrue; they only perform a CRC-32 check on the downloaded executable, which is not cryptographically secure.

Donations

So far for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, MSI (and more), have paid out a total of $0. The AMD vulnerability would have paid out ~10k USD if it was considered in scope.

If you found this article interesting or useful, you can buy me a coffee via my KoFi: https://ko-fi.com/mrbruhh

Timeline (DD/MM/YYYY)   

• 27/01/2026 - Vulnerability Discovered (by me)
• 06/02/2026 - Vulnerability Reported
• 06/02/2026 - Vulnerability Closed as won't fix/out of scope
• 06/02/2026 - Blog published
• 07/02/2026 - AMD backtracks and says they’ll look into it after all
• 09/06/2026 - Embargo on the vulnerability ends after 124 days