The RCE that AMD won't fix
90 points by achivetta
90 points by achivetta
Physical access and account compromise are one thing, but considering man in the middle out of scope sure is a choice... anyone can do that on any public WiFi.
Blog now says:
Temporarily taken down due to a request, will be back at a later date :)
I guess since it's been shared with the public, it is no longer Out of Scope...
This seems like an easy thing to fix. They already request the manifest over HTTPS and the individual files are on the same domain, so TLS are already in place. The fix is literally to replace 'http' with 'https' in the template they use to generate the manifest. If I were the recipient of the report, it would have been easier for me to fix it than to find an exception in the legalese.
The flaw is potentially very similar to https://notepad-plus-plus.org/news/hijacked-incident-info-update/ .
What I can't tell in the case of the AMD driver is whether there is a cryptographic checksum somewhere because only a part of the XML file is shown. It's also possible there is a verification at a later stage. Unfortunately the author doesn't say anything about these: neither their presence, nor their absence.
The article says:
I was hoping that AMD perhaps had some form of certificate validation to ensure that it could not download & 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.
But aren't drivers signed? An unsigned driver would trigger that warning you get in Windows...?
The updater appears to be downloading and running an installer. (Observe the InstallCommand stuff in the code snippets and screenshots.) The problem is that the installer can be replaced by a MITM attack. The attacker can provide any executable file, it doesn’t have to be a driver.
Full text:
The RCE that AMD won’t fix
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 anger, 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 its a little odd that they use their “Develpment” URL in production, it uses HTTPS so its perfectly safe.
The real problem starts when you open up this URL in your web browser, and realise that all of the executable download URL’s 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 & 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 issue, I thought it was worth reporting to AMD since it seemed to be a pretty severe issue.
Thanks for hacking on one of our programs!
We had a look at your report, and noticed that this issue falls under the following mentioned in the out of scope:
Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
Therefore I will have to close the report as out of scope
However it turned out to be considered “out of scope”, resulting in AMD not considering this to be a vulnerability.
Timeline (DD/MM/YYYY)
27/01/2026 - Vulnerability Discovered
05/02/2026 - Vulnerability Reported
05/02/2026 - Report Closed as wont fix/out of scope
06/02/2026 - Blog published