AMD’s first response to a working remote code execution path in its auto-updater was to close the report as “out of scope” and pay nothing. The patch, when it shipped 124 days later after the writeup trended on Hacker News, swapped plain HTTP for HTTPS but left a CRC32 checksum where a cryptographic signature belongs. The story is what defenders do during the months a vendor treats a working RCE as someone else’s problem.
What did AMD’s auto-updater get wrong?
The bug was a plaintext-download RCE. AMD’s AutoUpdate tool (AMDAutoUpdate.exe), installed alongside Ryzen Master and triggered by a Windows scheduled task every 15 days with elevated privileges, fetched its update list over HTTPS but downloaded the actual update executables over plain HTTP. It performed no certificate validation and no digital-signature check before running whatever it pulled down, according to TechSpot and the researcher’s Grokipedia writeup.
That turns any network-position attacker into a code-execution vector. The researcher, MrBruh (Paul LaRosa), a programmer from New Zealand per the Grokipedia analysis, spelled out the impact plainly: “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” (Winbuzzer). The attack surface runs from someone on the same Wi-Fi up to ISP-level interception via ARP poisoning, rogue access points, proxies, or BGP hijack.
How did the disclosure timeline play out?
MrBruh discovered the flaw on January 27, 2026 and reported it through AMD’s bug bounty program on February 6. AMD closed the report the same day, citing the program’s exclusion of MITM attacks. No fix, no bounty, no CVE at that point.
The report sat closed until MrBruh published his findings and the post gained traction on Hacker News. At that point AMD’s Product Security Incident Response Team (PSIRT) re-engaged, told MrBruh the issue was still under review, and asked him to take the post down while it worked on a fix, arguing the disclosure did not comply with the program’s terms, TechSpot reports.
What followed was an extended embargo negotiation. AMD said it would “likely need a longer embargo, as additional tools beyond Ryzen Master appeared to be impacted and would need releases,” according to correspondence Tom’s Hardware reviewed. MrBruh agreed first to a 100-day window, then was asked for more time again on the grounds that “multiple tools are affected” and that AMD’s “customers request additional time once the fixes are made available.” The patch landed June 9, 124 days after the initial report, with the embargo lifting the same day.
The eventual assignment was CVE-2026-40677, scored 7.7 under CVSS 4.0, with MrBruh credited in AMD’s bulletin (TechSpot). Mitigated versions are Ryzen Master 2.14.3, µProf 5.3, and Management Console 14.0.0.
Why did AMD call a working RCE ‘out of scope’?
AMD’s program, hosted on Intigriti and relaunched in 2024, caps payouts at $30,000 with the critical tier starting around $15,000, and explicitly lists man-in-the-middle attacks as out of scope (WebProNews). The company applied that exclusion here, marking the report “won’t fix / out of scope” because the flaw involved a MITM vector and affected optional utilities rather than core drivers or firmware.
On Hacker News, security commentator tptacek drew the distinction that got lost in the outrage: AMD was “not denying the vulnerability exists, but rather classifying it outside their bug bounty program scope” (HN discussion). That framing is accurate as far as the bounty decision goes. It is also the crux of the disagreement. The thread turned on whether a plaintext-HTTP download channel that yields elevated remote code execution should ever be excludable from a program’s scope, or whether operators read “out of scope for the bounty” as “out of scope for our threat model,” which it is not.
A scope decision is a payout decision. It is not a remediation decision, and the 124 days between report and patch show what happens when a vendor treats the two as the same thing.
The bounty dispute is where AMD’s handling went from defensible to damaging. According to Gamers Nexus reporting cited by TechSpot, AMD rewrote its bounty rules to forbid researchers from disclosing vulnerability information without AMD’s written consent even when a report is deemed ineligible or out of scope, then applied that new clause retroactively to MrBruh’s already-removed blog post as grounds to withhold the roughly $10,000 an RCE-class bug would command. AMD accused the researcher of breaking a rule that did not exist when he wrote the post.
What did AMD’s patch actually fix?
AMD told MrBruh that all update communications now use HTTPS and that updates undergo signature verification. MrBruh verified the HTTPS part. The signature part is where the claim breaks down.
He found that the re-engineered updater validates the downloaded executable with a CRC32 checksum, not a cryptographic signature (TechSpot, Tom’s Hardware).
CRC32 is an error-detection code, not an integrity mechanism. It catches accidental corruption from a flipped bit. It does not resist an attacker who can choose the replacement payload, because generating a binary with a matching CRC32 is a millisecond computation. A checksum the attacker can satisfy is not a signature.
There is a second problem. MrBruh reports a separate redirection bug that may prevent the updater from updating itself, and per a Reddit user cited by Tom’s Hardware, the vulnerable code path was reportedly never being called in the first place, meaning the updater was already broken and could not self-update. The updater that cannot update itself is a known failure mode, and it is why MrBruh recommends users fully uninstall AMD software and download the latest versions manually from amd.com.
What should operators do while a vendor treats a disclosed RCE as out of scope?
When a vendor declines to patch a disclosed vulnerability with a working proof of concept, the mitigation does not wait for the vendor. For the AMD case specifically, three controls apply during any window where the updater is untrusted:
- Block the updater’s outbound HTTP egress. If
AMDAutoUpdate.execannot reach its plaintext download endpoint, it cannot fetch a substituted payload. Egress filtering at the host or firewall level denies the attack path regardless of whether AMD considers it in scope. - Uninstall the tool and disable the scheduled task. Ryzen Master, µProf, and Management Console are optional utilities, which is part of why AMD scoped the report out. That cuts both ways: if they are optional, removing them removes the attack surface. MrBruh’s recommendation is a full uninstall plus a manual download from amd.com (TechSpot).
- Assume the disclosed path is exploitable until a signed update arrives. The working PoC is public. “Out of scope” does not retract a proof of concept.
What does this do to threat models that assume patches arrive?
Most patch-management programs budget for a vendor fix to land within a known window, often the industry-standard 90 days. A vendor that closes a report as out of scope the day it arrives, then takes 124 days to ship a fix after public pressure, breaks that assumption in two directions at once.
First, the fix may never come under normal process. AMD shipped this patch only after the writeup trended and PSIRT re-engaged. Absent that public pressure, the report stayed closed with no remediation timeline attached. A threat model that assumes disclosed, PoC-confirmed vulnerabilities get patched is assuming a social process, not a technical one.
Second, when the fix does come, it may not close the class of bug. HTTPS over the wire plus CRC32 on the artifact closes the original interception path but leaves the update channel trusting a non-cryptographic check. An operator who applies the “fixed” version and drops their guard has traded one known-broken state for a less-obvious one.
The broader pattern, plaintext-HTTP update channels yielding RCE, is not unique to AMD. The operator-side lesson is structural: treat vendor update mechanisms as untrusted until they demonstrate code signing against a pinned or root-trusted certificate, not merely TLS on the transport. A vendor that classifies the interception of its own update channel as out of scope is telling you where it ranks that risk. Budget accordingly.
Frequently Asked Questions
Why is CVE-2026-40677 only a 7.7 and not a 9.x like other network RCEs?
The 7.7 under CVSS 4.0 likely reflects an Adjacent rather than Network attack vector, because exploitation requires the attacker to already sit between the victim and AMD’s download endpoint. CVSS treats same-Wi-Fi, rogue-AP, ISP, or BGP-hijack positioning as a harder precondition than a remotely reachable service. Environments where an attacker can realistically obtain that network position should read the 7.7 as understated rather than comforting.
How do I disable the updater across a fleet without uninstalling Ryzen Master on each machine?
The control point is the Windows scheduled task that launches AMDAutoUpdate.exe every 15 days, not the binary itself. Fleet operators can delete or disable that task via Group Policy Preferences or a Configuration Manager baseline, then block outbound HTTP to AMD’s update host at the perimeter firewall. That removes the elevated execution path centrally while leaving the tuning tools in place for the users who depend on them.
Does blocking the updater’s network access break Ryzen Master itself?
No. AMDAutoUpdate.exe is a separate background component responsible for fetching new versions, not a runtime dependency of Ryzen Master’s monitoring and tuning functions. Blocking its outbound HTTP or disabling its scheduled task halts the update checks; the utility continues to read sensors and apply profiles against the already-installed driver. Users lose automatic version pulls, which during this disclosure window is the intended outcome.
What does AMD’s retroactive rule change signal to future vulnerability reporters?
The clause AMD added forbids disclosure of ineligible reports without written consent, which applies to reports the program already decided not to pay for. Researchers submitting to AMD now carry a gag risk on bugs the company declines to fix or reward. The probable behavioral shift is fewer private reports to AMD and more direct full-disclosure posts or brokered submissions, because the program no longer offers a clean exchange of bounty for silence.
How does AMD’s 124-day patch window compare to standard coordinated disclosure deadlines?
The de facto industry reference is Google Project Zero’s 90-day disclosure deadline, after which bugs are published regardless of patch status. AMD’s 124 days from report to patch exceeded that benchmark, and the remediation work appears concentrated in the window after Hacker News traction forced PSIRT to re-engagement, not across the four months the report sat closed. The published 124-day figure counts from submission, but the active fixing looks back-loaded onto the post-pressure period.