How an Insecure Update Flow Exposed AMD Systems to RCE

Software update clients are, by design, some of the most dangerous pieces of code running on an operating system. They possess the authority to fetch executables from the internet and run them with elevated privileges. When an updater fails to verify the integrity of what it downloads, it ceases to be a maintenance tool and becomes a pre-installed backdoor.

This classic failure pattern recently emerged in AMD's AutoUpdate software, an optional utility bundled with tools like AMD Ryzen Master. Discovered by security researcher "MrBruh" after decompiling the utility to investigate intrusive console pop-ups, the vulnerability allows for trivial Remote Code Execution (RCE) via a Man-in-the-Middle (MITM) attack.

HTTP Payloads and Zero Validation

The mechanics of the vulnerability are elementary. The AutoUpdate binary retrieves its update configuration from an XML file. The initial request to fetch this XML is secure, pointing to an HTTPS URL defined in the application's app.config (which, curiously, was still configured to use AMD's internal development domain in the production release).

However, the security boundary collapses once the XML payload is parsed. The executable download URLs specified inside the XML file use plain text HTTP rather than HTTPS.

For an attacker positioned on the local network, a compromised router, or a malicious ISP, intercepting this HTTP traffic is trivial. But transport-layer security is only the first line of defense. The fatal flaw lies in the client-side binary's complete lack of validation. Decompilation of the AutoUpdate software revealed that it performed no digital signature verification or cryptographic hash checks on the downloaded executables. It simply fetched the binary over unencrypted HTTP and executed it immediately.

The Bug Bounty Scope Paradox

When the researcher reported this trivial RCE to AMD via their bug bounty platform, managed by Intigriti, the submission was promptly rejected and closed as out of scope. The justification was twofold: the vulnerability relied on a MITM attack scenario, and it affected an "optional" tool.

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

This highlights a persistent disconnect in corporate threat modeling. Labeling a utility "optional" ignores how developers and power users actually interact with hardware. Ryzen Master is widely used to tune CPU performance, and its updater runs with administrative privileges. Furthermore, dismissing MITM attacks as out of scope ignores the reality of modern network environments, where public Wi-Fi, DNS hijacking, and compromised local gateways are common vectors.

It was only after the researcher published their initial findings on Hacker News that AMD's internal Product Security Incident Response Team (PSIRT) intervened, bypassed the third-party triage decision, and opened an internal review.

The 124-Day Embargo for an 'S'

The coordination process that followed illustrates the friction often encountered in vulnerability disclosure. AMD requested that the researcher take down the public write-up and agree to an extended embargo. While the industry standard for coordinated disclosure is 90 days, AMD requested more time, citing that multiple optional tools beyond Ryzen Master were affected and required coordinated updates.

Ultimately, it took 124 days from the initial report for the embargo to lift on June 9th. The irony of this timeline is not lost on network engineers: on the server side, mitigating the immediate threat could have been as simple as appending an "s" to the protocol scheme in the hosted XML file to force HTTPS downloads.

To complicate matters, the researcher noted that the auto-updater mechanism may have already been non-functional for an entirely separate reason—specifically, a broken backend configuration resulting from AMD changing how they host their software packages.

Hardening the Update Pipeline

For developers building desktop software or agent utilities, this incident serves as a textbook case of how not to design an update pipeline. Relying solely on transport-layer security (HTTPS) is a common anti-pattern. A robust update mechanism must implement defense-in-depth:

• Enforce HTTPS Everywhere: Both the update metadata (XML/JSON) and the binary payloads must be fetched over TLS.
• Cryptographic Signature Verification: The update client must contain a hardcoded public key. Before any downloaded binary is executed, the client must verify its cryptographic signature against this key. If the signature is missing or invalid, the payload must be discarded.
• Strict Input Validation: Parse configuration files and update manifests using secure, hardened parsers to prevent secondary injection vulnerabilities.

Relying on the assumption that an attacker cannot intercept network traffic is a design flaw that will eventually be exploited. When that utility runs with system-level privileges, the cost of that assumption is complete system compromise.