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 Initial Discovery
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 appears perfectly safe.
However, 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.
Missing Signature Verification
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.
For more on why signature verification matters, see our deep dive into software supply chain security and how companies like Microsoft handle updates through their June 2026 Patch Tuesday advisories.
The Bug Bounty Bypass
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.
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.
Public Pressure and Backdown
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.
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.
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.
The Embargo Dilemma
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.
The Catch-22 Situation
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: A Second Bug Makes the Vulnerability Not Exploitable
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.
AMD's Patch Details
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.
Technical Analysis of the Vulnerability
Let's dive deeper into the technical aspects of this vulnerability. The core issue lies in how AMD's AutoUpdate software downloads and executes updates.
HTTP Downloads Without Encryption
The first vulnerability is the use of HTTP instead of HTTPS for downloading executable files. While the main update manifest URL uses HTTPS, the actual download links for the executables inside that manifest use plain HTTP. This creates a classic man-in-the-middle attack vector where an attacker can intercept the network traffic and replace the legitimate executable with a malicious payload.
Missing Code Signing Verification
The second, and arguably more critical, vulnerability is the lack of cryptographic signature verification. When software downloads an update, it should verify that the executable has been signed by AMD's private key. This provides cryptographic proof that the file hasn't been tampered with and came from AMD itself.
Instead, AMD's AutoUpdate software simply downloads the file and executes it without any verification. This means that anyone who can intercept the network traffic (through Wi-Fi hijacking, router compromise, ISP manipulation, or nation-state surveillance) can replace the downloaded file with malware.
Why CRC-32 Isn't Security
AMD later claimed they implemented signature verification, but in practice, they only use CRC-32 checksums to verify file integrity. CRC-32 is a hash function designed for error-checking in data transmission, not cryptographic security. An attacker who can modify the downloaded executable can also easily recalculate a new CRC-32 checksum, making this "verification" completely ineffective against malicious attacks.
Industry Standards and Best Practices
What Proper Update Security Looks Like
Professional software vendors follow several key practices when implementing update mechanisms:
- HTTPS for all connections: Every URL used in the update process should use HTTPS with proper certificate validation
- Cryptographic signatures: All executables should be signed using asymmetric cryptography (RSA, ECDSA)
- Certificate pinning: The client should verify the server's certificate against a known set of trusted certificates
- Secure storage: Private keys used for signing should be stored in hardware security modules (HSMs)
- Update manifest signatures: The entire update manifest should be signed to prevent tampering
- Atomic updates: Updates should be applied atomically with rollback capability
AMD's AutoUpdate software failed on multiple counts in this area, creating a textbook example of insecure update mechanisms.
CVE-2026-40677 Analysis
CVE-2026-40677 was published on June 12, 2026, approximately 124 days after initial disclosure. The CVE description indicates a remote code execution vulnerability in AMD's AutoUpdate software.
CVSS Score Assessment
Based on the vulnerability characteristics:
- Attack Vector: Network (NV)
- Attack Complexity: Low (LC)
- Privileges Required: None (NR)
- User Interaction: None (NU)
- Scope: Unchanged (UC)
- Confidentiality Impact: High (HC)
- Integrity Impact: High (HI)
- Availability Impact: High (HA)
This would likely score a CVSS vector of: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which equals a critical score of 9.8.
Impact Assessment
The potential impact is severe:
- Attackers can deploy ransomware on affected systems
- Trojans and backdoors can be installed without user consent
- Botnet recruitment becomes trivial for attackers on the same network
- Corporate networks could face mass compromise through a single compromised workstation
The Timeline of Inaction
Phase 1: Initial Disclosure (February 6, 2026)
- Vulnerability discovered and reported to AMD via Intigriti
- Bug bounty program quickly rejects as "out of scope"
- Blog post is published detailing the vulnerability
Phase 2: Public Backlash (February 7, 2026)
- Hacker News discussion generates significant attention
- AMD PSIRT contact researcher and agrees to review
- Researcher complies with request to take down blog post
Phase 3: The Wait (February 7 - June 9, 2026)
- Over three months of waiting for AMD's response
- Extended embargo periods requested without clear timeline
- Only two days' notice before embargo end date
Phase 4: Patch and Disclosure (June 9-12, 2026)
- Embargo ends after 124 days
- CVE-2026-40677 published
- Patches released for affected software including Ryzen Master
Critical Timeline Analysis
The 124-Day Embargo Problem
The 124-day embargo period exceeds industry standards and raises serious questions about AMD's security practices:
- NIST guidelines: Recommend 90-day disclosure window
- Google Project Zero: Uses 90-day policy with 14-day grace period
- Microsoft: Typically resolves within 30 days for security updates
- Canonical/Ubuntu: 90-day policy with possible extensions for complex fixes
AMD's justification that "additional tools beyond Ryzen Master appear to be impacted" is invalid because:
- The fix (adding 's' to HTTP URLs) is trivial
- Other tools should have received patches on the same timeline
- The extended wait put millions of users at risk unnecessarily
Conclusion
This case highlights several problematic patterns in the vulnerability disclosure process:
- Out-of-scope justifications: Bug bounty programs excluding MITM attacks while the same vulnerabilities could be exploited in practice
- Extended embargoes without clear timelines: Demanding researchers stay silent for over 120 days
- False security claims: Promising signature verification but only delivering CRC-32 checksums
- Confusing security practices: Using HTTP for executable downloads despite HTTPS being available
- Broken update mechanisms: Redirect issues that prevent the updater from working at all
For AMD users with the affected software installed, I highly suggest fully uninstalling everything, then grabbing the new versions from their website directly.
Recommendations for Users
- Uninstall all AMD software with auto-update functionality
- Download installation packages directly from amd.com
- Use network monitoring tools to detect suspicious traffic
- Consider using third-party update management for critical software
- Regularly audit installed software for unnecessary auto-update features
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