Source linked

124 Days for AMD to Add One Letter to Fix an RCE

mrbruh.com@systems_wire3 hours ago·Cybersecurity·2 comments

A trivial MITM vulnerability in AMD's AutoUpdate let attackers replace executables with any payload - and the fix was simply changing HTTP to HTTPS.

amdintigritiryzen masterremote code executionvulnerability disclosurebug bounty

A nagging console window on a new gaming PC led to a trivial Remote Code Execution vulnerability in AMD’s AutoUpdate software — and a 124-day slog to get AMD to add a single character to a URL. Researcher MrBruh decompiled the updated client and found the update URL stored in the program’s app.config pointed to an XML file that itself contained executable download URLs using plain HTTP. No certificate validation. No code signing checks. The updater downloaded whatever the XML told it to and executed it immediately. An attacker on the same network, or upstream at an ISP, could inject a malicious binary in a classic Man-in-the-Middle attack.

AMD’s Bug Bounty Said MITM Was Out of Scope

MrBruh reported the finding via Intigriti, the bug bounty platform AMD uses for initial triage. AMD’s program terms explicitly exclude man-in-the-middle attacks. The report was closed as out of scope — no bounty, no fix. After the story hit Hacker News, AMD’s internal PSIRT team reached out, asked the researcher to take down the blog post, and said they would investigate. They requested a 90-day embargo. Then they asked for more time, claiming the issue might affect “multiple optional tools” beyond Ryzen Master.

124 Days to Change One Letter

The fix? Adding an s to the HTTP URLs in the hosted XML file. The researcher waited 87 days before pushing back, then agreed to a June 9th disclosure date — 124 days total from initial disclosure. AMD issued a CVE and offered security researcher credit, but no bounty, maintaining the MITM scenario was out of scope. MrBruh notes that the patch itself is trivial; the real vulnerability was the process that let a simple SSL upgrade drag on for four months while millions of systems remained exploitable. The full disclosure blog post includes timelines and direct quotes from AMD’s security team. The kicker? MrBruh doubts the patch even matters, because the auto-updater is completely broken in design. This case shows that even for a vulnerability with a one-character fix, a company’s disclosure policy — not the technical difficulty — becomes the bottleneck. Expect more researchers to think twice before reporting similar issues to AMD’s program in the future.


Source: The RCE that AMD wouldn't fix
Domain: mrbruh.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.