The RCE that AMD won't fix

Nature and Severity of the Issue

• AMD’s Windows AutoUpdate tool fetches executables over plain HTTP from an old ati.com domain, apparently without signatures or checks.
• Commenters widely characterize this as a trivially exploitable remote code execution pathway with elevated privileges.
• Several note this is unusually bad given how broadly deployed the software likely is and how easy the fix (HTTPS and/or signed binaries) would be.

Attack Vectors and Practical Exploitation

• Multiple vectors discussed: compromised home routers (bad DNS), rogue devices on the LAN (DHCP/DNS/ARP spoofing), malicious public or spoofed Wi-Fi (e.g., “Airport WiFi”), and even BGP hijacks at ISP level.
• Clarification that DNS poisoning and rogue DHCP are forms of MITM; they need not be “exotic.”
• Some argue this only works when an update is available and the scheduler runs, but others respond that an active attacker can just serve a fake “update” whenever the client checks.
• A few downplay it as requiring an already-compromised network; others counter that the network should never be assumed trustworthy.

MITM and AMD’s Bug Bounty Response

• AMD’s program explicitly excludes “man-in-the-middle” and similar scenarios from scope; the report was closed as “out of scope.”
• There is debate whether “out of scope” for bounty also implies “won’t fix”; some say the blog title exaggerates, others think AMD’s wording and inaction are effectively a de facto WONTFIX.
• Many argue that excluding MITM from payment is fine, but using that as a reason not to fix a high‑impact issue is “indefensibly incompetent.”

Automatic Updates and User Behavior

• Disagreement over auto-updates: some see disabling them as common-sense security; others argue most users would be far less secure without them.
• One commenter incorrectly claims auto-updates “almost never” fix vulnerabilities; others dispute that.
• Clarification that auto-update is only an RCE vulnerability when third parties can inject unauthorized code; intended updates from a trusted vendor are not a “vulnerability” by themselves.

Platform and Mitigation Discussion

• Linux users note that distro package managers and in-kernel drivers avoid running vendor updater junk, though HTTP-based repos and signature verification bugs are mentioned as their own risk area.
• Several users respond by uninstalling or blocking AMD’s updater and, in some cases, blocking all outbound HTTP.
• Some suggest corporate security teams may ban the AMD updater or even consider avoiding AMD hardware if this remains unfixed.

Broader Commentary on Vendors and Security

• Repeated theme: hardware vendors prioritize shipping new products over secure, well-maintained software.
• Debate whether this reflects true incompetence or rational but shortsighted cost–benefit decisions.
• A few express that such a blatant, easy-to-fix flaw — especially if left unaddressed — seriously damages trust in AMD’s security culture.