The RCE that AMD wouldn't fix

It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.

> 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 [...] 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.

So solves the MITM, but massive infection is still trivial if someone compromises the webserver.

AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.

The "signature verification" in the fix being CRC32 is pretty hilariously clueless.

AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share.

For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.

> In my frustration, I decided to punish this software

Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.

Thank you for looking into this, I also have the annoying pop-up and have been suspicious of it…

> If you are an AMD user...

Don't bother to use Windows?

There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.

If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.

Multi billion dollar company, by the way.

Congratulations, you found the government backdoor!

I think we can all agree that MiTM is a valid attack vector and this should have paid out the bounty. AMD won't do it, but perhaps we can crowdsource it - the dude deserves it. Join me in doing this: https://ko-fi.com/mrbruhh (identical link to the one in the write up, feel free to verify).

I started it with $100 - https://ko-fi.com/transactions/03df753c-09b0-4972-8e53-adf06...

AMD software is often utter trash.

I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.

My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.

That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.

But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!

Seems like white hat work is pretty fruitless nowadays. Disappointing.

There's two requests involved for the auto updater, one to grab the XML file, and one to grab the driver file over plain http.

If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.

Seems like white hat work is pretty fruitless nowadays. Disappointing.

They keep choosing to work whitehat instead of blackhat, which is all AMD ever wanted.

So solves the MITM, but massive infection is still trivial if someone compromises the webserver.

MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope.

MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.

Why would anyone ever exclude true mitm?

Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned.

The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want.

Although I suppose the aforementioned problem has significant implications beyond dns…

Out of scope in this case means "we don't wanna pay you"

Out of scope does not necessarily mean out of impact. It is merely a question of how far a company wants to be responsible for the environment their software is run in. Most of the time that answer is "not much."

But I use a Wi-Fi password, so my phone says it's secure!

Thank you for looking into this, I also have the annoying pop-up and have been suspicious of it…

Multi billion dollar company, by the way.

> If you are an AMD user...

Don't bother to use Windows?

Congratulations, you found the government backdoor!

I started it with $100 - https://ko-fi.com/transactions/03df753c-09b0-4972-8e53-adf06...

They keep choosing to work whitehat instead of blackhat, which is all AMD ever wanted.

likewise. i'm bewildered throughout the years.

my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.

> In my frustration, I decided to punish this software

Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.

I got so mad at plex/jellyfin's crap I vibe coded an entire entertainment system out of spite.

Works great!

AMD software is often utter trash.

I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.

The "signature verification" in the fix being CRC32 is pretty hilariously clueless.

Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.

The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.

Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux

It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.

Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.

Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.

They should have done base64 encryption before the crc32. noobs

But I use a Wi-Fi password, so my phone says it's secure!

I got so mad at plex/jellyfin's crap I vibe coded an entire entertainment system out of spite.

Works great!

MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope.

MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.

I'd even count this as "having local access to the device", as that is what is needed to install such a cert

Why would anyone ever exclude true mitm?

Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned.

The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want.

Although I suppose the aforementioned problem has significant implications beyond dns…

>Why would anyone ever exclude true mitm?

Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.

Out of scope in this case means "we don't wanna pay you"

Apparently it also means "We don't want to pay our engineers to fix this".

likewise. i'm bewildered throughout the years.

Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.

Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux

They should have done base64 encryption before the crc32. noobs

The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.

Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)

But despite that, I also believe AMD would be better off just implementing CUDA.

More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.

Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.

The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.

A manager somewhere made the embarrassingly wrong decision to not fix this, and they’re too egotistical to correct their mistake.

That’s my take.

Apparently it also means "We don't want to pay our engineers to fix this".

>Why would anyone ever exclude true mitm?

Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.

Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.

I'd even count this as "having local access to the device", as that is what is needed to install such a cert

I think it's fair to say that requiring local administrative access to the device is out of scope, since you have already completely pwned the device in that case, which is what what you need to install a CA cert on any OSes.

The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit.

Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.)

But despite that, I also believe AMD would be better off just implementing CUDA.

The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.

A manager somewhere made the embarrassingly wrong decision to not fix this, and they’re too egotistical to correct their mistake.

That’s my take.

Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.

Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.

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.

amd_appconfig

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.

amd_updatexml

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.

amd_installupdates

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.

amd_disclosure

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.

amd_reddit_post

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.

Great Job AMD GIF

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

Hacker Times