AMD's updater downloaded code over plain HTTP and ran it. The bug bounty called it out of scope
AMD's AutoUpdate tool fetched executables over unencrypted HTTP and ran them with zero signature checks — a textbook remote-code-execution path. The bounty program rejected the report as out of scope, until a blog post hit Hacker News and AMD's own security team reversed in a day.
Disclosure ran 124 days, when the fix was essentially adding an 's' to a couple of URLs. The eventual "signature verification"? A CRC32 checksum — which any attacker can trivially recompute.
Known security voices reframed it: AMD never denied it was a vulnerability, only that it was in scope — and at big vendors, bounty teams are measured on payouts. The dark comedy: the updater may be too broken to exploit.
An RCE hiding in a tool everyone forgot
The write-up describes AMD's AutoUpdate — bundled with Ryzen Master and other optional utilities — pulling its download manifest over HTTPS but then fetching the actual executable over plain HTTP, with no signature validation, and running it immediately. Anyone positioned on the network, or at the ISP, could swap in a malicious binary: remote code execution on the machine. One detail betrays how forgotten the feature was: it still pointed at an old ATI domain.
The timeline reads as farce. Discovered January 27, reported February 6 and rejected as out of scope (MITM, optional tools), reversed by AMD February 7 once the post gained traction, embargo lifting June 9 — 124 days for a fix the researcher described as adding an s to a couple of HTTP URLs.
"Out of scope" was a budget decision, not a security one
The most clarifying comment came from a familiar security voice. tptacek reframed the rejection:
"AMD didn't deny it was a vulnerability; they denied it was in the scope of the bounty program… at giant tech companies, the incentive is to pay out bounties — there are people on the vendor's team whose performance is measured in part by how much the program pays out."
A YC engineer called the scope call indefensible on its own terms: "It's ridiculous to consider MITM attacks out of scope for taking over your computer… it's best to just assume the whole internet is MITMed."
The fix is funnier than the bug
When AMD finally shipped "signature verification," the thread checked what that meant. A Stockholm-based engineer didn't hold back:
"The 'signature verification' in the fix being CRC32 is pretty hilariously clueless."
CRC32 is an error-detection checksum, not a cryptographic signature — an attacker who alters the payload just recomputes it. An engineer who read the actual write-up gave the grounded version: a forgotten non-default updater, AMD "incompetent at making software," endless extension requests, and the tool eventually ripped out entirely.
The punchline: it may not even work
The write-up's final irony is that the vulnerability might be unexploitable in practice — AutoUpdate fails to handle domain redirects and crashes before it reaches the vulnerable path. The bug is real; the program that contains it is too broken to run.
That's the part that should worry AMD more than the CVE. A self-described diehard AMD fan listed years of driver and tooling failures, including a default fan curve that cooked his GPU for two years. "White hat work is pretty fruitless nowadays," a commenter sighed. When a clean report gets bounced on a technicality and the fix is a checksum, the lesson disclosed isn't about one updater. It's about what a vendor's security process actually optimizes for.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Zed says software is made between commits, and built a version control system to prove it
Zed's DeltaDB throws out the commit as the unit of version control. It records every individual edit, links each code change to the conversation that produced it, and promises pull-request ceremony just "disappears." The thread's reply: another editor we begged not to go AI-first.