AMD AutoUpdate Remote Code Execution Vulnerability

Summary of the Vulnerability

AMD's AutoUpdate software contained a critical Remote Code Execution (RCE) vulnerability that allowed a Man-in-the-Middle (MITM) attacker to replace legitimate software updates with malicious executables. The flaw existed because the software downloaded update manifests via HTTPS but fetched the actual executable files over unencrypted HTTP without performing any cryptographic signature verification on the downloaded files.

Technical Root Cause

The vulnerability stemmed from a failure to secure the end-to-end delivery chain of software updates. While the initial update URL stored in the app.config file used HTTPS, the resulting XML manifest contained download links for executables that used plain HTTP.

Because the AutoUpdate software did not validate the digital signatures of the downloaded executables, it would immediately execute any file received from the HTTP URL. This allowed any attacker with network access—such as a malicious actor on a local network or an ISP-level entity—to intercept the HTTP request and serve a malicious payload instead of the official AMD update.

Disclosure Timeline and Response

The process of reporting and patching this vulnerability spanned 124 days, characterized by significant friction between the researcher and AMD's security teams.

  • Discovery and Initial Report: The vulnerability was discovered and reported on February 6, 2026.
  • Initial Rejection: AMD's third-party bug bounty platform, Intigriti, initially closed the report as "out of scope," citing that Man-in-the-Middle attacks were not eligible for bounties under their current guidelines.
  • Reversal: After the researcher published a blog post and the issue gained traction on Hacker News, AMD's internal Product Security Incident Response Team (PSIRT) reopened the case.
  • Embargo and Delay: AMD requested the researcher remove the blog post and requested an extended embargo period beyond the industry-standard 90 days, claiming that multiple tools beyond Ryzen Master were affected.
  • Resolution: The embargo ended on June 9, 2026, 124 days after the initial disclosure.

The Patch and Remaining Security Gaps

AMD's eventual fix involved moving the auto-updater functionality from the installer to the application layer and transitioning all update communications to HTTPS.

However, the researcher found that AMD's claim of implementing "signature verification" was inaccurate. Instead of using cryptographically secure signatures, AMD implemented a CRC-32 check. As noted by community members in the Hacker News discussion:

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

Because CRC-32 is an error-detecting code and not a cryptographic hash or signature, it does not protect against intentional tampering. If a web server were compromised, an attacker could simply calculate the CRC-32 of a malicious file and update the manifest, making the infection trivial.

Accidental Mitigation

Interestingly, evidence suggests the vulnerability may have been accidentally unexploitable in some versions due to a separate software bug. AMD shifted its hosting from ati.com to drivers.amd.com, but the AutoUpdater program reportedly could not handle the resulting HTTP redirection. This caused the program to crash or lock up before it ever reached the code responsible for downloading the insecure HTTP executables, creating a "Catch-22" where the updater was too broken to be exploited, but also too broken to be updated with the security fix.

Sources