Just another unique way to voice out.: AMD's AutoUpdate: The Bug Bounty Says It's Not a Bug

A solo researcher named MrBruh published, on 11 June 2026, the full technical write-up of a remote code execution in AMD's auto-update software, after AMD spent 124 days first declining to fix it, asking him to keep the write-up offline, then patching it with the cheapest possible change: an s on a handful of HTTP URLs and a CRC-32 check on the downloaded executable. The bug is the updater. The story is the bounty program that calls the updater correct.

The vulnerability, in 200 words

The researcher was annoyed by a console window popping up periodically on his new gaming PC, traced it to AMD's AMDAutoUpdate.exe, and decompiled it. The application reads its update-server URL from a local app.config. The URL for the manifest itself is HTTPS, which is fine. The manifest is an XML file that lists the download URLs for the actual updater executables — and every one of those is plain HTTP. The application downloads the executable, performs no signature check, and runs it. The MITM surface is "anyone on the network path between you and the AMD update server," a meaningful threat model since the update server is also the server whose HTTPS endpoint is being trusted. This is a static analysis finding, reproducible without leaving your desk.

That finding would be worth roughly $10,000 on AMD's reported payout schedule if the bug bounty program considered MITM in scope. The researcher notes that in the post: "The AMD vulnerability would have paid out ~10k USD if it was considered in scope." It was not considered in scope, because AMD's bug bounty program, run through the Intigriti platform, excludes MITM attacks.

What AMD did over the next 124 days

The initial submission was rejected as out of scope the same day, citing the MITM exclusion. Within 24 hours of the original Hacker News thread going up, AMD's PSIRT (Product Security Incident Response Team) reached out and said it would review the report after all, but asked the researcher to take the blog post down "until they patched the issue." He agreed, in retrospect calls this the wrong call. The PSIRT confirmed a CVE would be issued, a fix shipped, and the researcher credited, and asked for a longer embargo citing "additional tools beyond Ryzen Master" being affected. The industry standard for vulnerability disclosure is 90 days; AMD's request was for longer.

The researcher waited 87 days, then went back to AMD to ask for a status update. AMD had not proactively communicated. A couple of days before the agreed-upon disclosure window, AMD told him what the fix was. AMD's own communication describes the patch as: in Ryzen Master, the auto-updater was moved from the installer to the application layer, all update communications now use HTTPS, and updates undergo signature verification. MrBruh decompiled the post-patch binary and reports that the architectural change happened but the signature-verification claim is empty: HTTPS is in, but the only integrity check on the downloaded executable is CRC-32, which is not cryptographically secure. He republished the write-up at 124 days from initial disclosure.

Why "we do not pay for MITM" is the wrong frame

The HN thread is a real argument, not the usual pile-on. tptacek draws the line: MITM via local CA cert install is out of scope (that's local access), but MITM because the updater used HTTP and shipped no signature is the in-scope case — "get tae fuck, fix it pronto." amiga386 agrees with the narrow distinction, and tptacek's broader framing later in the thread is the most quotable line: out of scope does not necessarily mean out of impact, it is just a question of how far a company wants to be responsible for the environment its software runs in, and most of the time the answer is "not much." Both are saying the same thing from different directions: the bounty program is not the entire security program, but the threat model the bounty program encodes is the threat model the engineering org ships against.

The deeper issue is that "out of scope" is doing two jobs in the public conversation. It is a triage rule — we will not pay bounties for this class of report — and a defensive talking point — we do not consider this class of issue a vulnerability. The AMD post shows both happening to the same report. The triage decision was defensible in isolation. The talking-point deployment was not, because the report was true: the code was vulnerable, the network path was unverified, the downloaded binary was executed, and a CRC-32 is not a signature. Saying "out of scope" in public, after the researcher took the post down in good faith and waited 87 days, is the part that turns a triage call into a process failure.

The CRC-32 is the kicker

The patch closes the trivial MITM (the s) and adds a check that visibly looks like verification (the CRC-32) without doing the work verification requires. A CRC-32 detects accidental corruption. An attacker who can MITM the response can also forge a CRC-32. The HN thread picks this up immediately — robotnikman called the framing "hilariously clueless," and a few comments down the thread someone posted the driest possible one-liner: "They should have done base64 encryption before the crc32. noobs." The whole thread knows. The interesting question is what the patch is for: the cheapest defensible fix is the one you ship when the bar is "we issued a CVE and credited the researcher," not the one you ship when the bar is "this updater is no longer the easiest way to pwn a Windows box."

The bug bounty is the new attack surface

The thing this post is actually about is not AMD. AMD is the example. The pattern: a vendor runs a bug bounty program on Intigriti or HackerOne or Bugcrowd, writes a scope document that excludes the cheapest class of vulnerability to actually fix (MITM, social engineering, physical access), and uses the program as a marketing channel. The researcher, in the post, does the arithmetic: he has reported vulnerabilities to Google, ASUS, AMD, TP-Link, and MSI, and the cumulative payout is $0. The scope document is the new attack surface for the same reason the EULA is the attack surface: it is the document a vendor writes to constrain the obligation they have taken on. "MITM is out of scope" sounds technical and is, in practice, a way of saying "we will not pay you to find a class of bug we have decided not to fix."

What this means for you

If you ship a desktop auto-updater, treat the updater as the security-critical surface it actually is. HTTPS on the manifest is necessary and not sufficient. The downloaded payload needs a signature verified against a public key embedded in the installed client, not a checksum verified against a value fetched in the same transaction.
If you buy a product with a bug bounty program, read the scope document. "MITM out of scope" on a network-connected desktop application is a yellow flag. "Social engineering out of scope" is normal. "MITM out of scope on an updater that talks to a network" is the AMD pattern.
If you consume AMD software (AutoUpdate, Ryzen Master, Adrenalin), the practical advice is: do not run AMD's updater on a machine that matters. Pull the installers from amd.com yourself, verify the SHA-256 against the published value, and disable the auto-update service.
If you are a security researcher: the disclosure timeline MrBruh documents is the playbook you should expect from a large-vendor PSIRT in 2026. Your leverage is the public write-up; do not take it down without a written commitment on the disclosure date.

What to do this week

# 1. Check whether AMD's auto-updater is running on your box.
#    The vulnerable service is AMDSoftwareInstaller.exe / AMDAutoUpdate.exe.
sc query "AMD Installer" 2>/dev/null
# If the service is set to AUTO_START, you are exposing the
# update surface to the network. Disable it and pull drivers
# manually from amd.com if you want the CRC-32 as your floor.

# 2. If you maintain a desktop auto-updater, audit the
#    download chain end to end. The questions:
#      - Is the manifest HTTPS? (should be)
#      - Are payload URLs in the manifest also HTTPS? (AMD did not)
#      - Does the client verify a signature against a public
#        key embedded in the installed client? (CRC-32 is not
#        a signature. SHA-256 of a value fetched in the same
#        transaction is not a signature. The key has to be
#        pinned in the installer.)

# 3. If you participate in a bug bounty as a reporter, read
#    the AMD post as a case study. The 87-day silence after
#    the post was taken down, the "additional customer review"
#    justification, and the two-days-before-embargo patch
#    notification are all documented. Your leverage is the
#    public write-up; do not take it down without a written
#    commitment on the disclosure date.

The original take: the scope document is the disclosure policy

The HN consensus — AMD should fix the underlying problem, not the trivial case — is the right operational complaint and the wrong strategic one. The strategic complaint is that the disclosure policy, as encoded in the bug bounty scope document, is itself the product the security team ships. The scope document tells the research community which classes of vulnerability AMD will pay for, tells the engineering org which classes to expect, and read literally, tells you that AMD does not pay for MITM. The threat model is the product.

The CRC-32 patch is the receipt. It is the cheapest defensible response to a CVE that is in scope only because the disclosure went public and the researcher had a paper trail. The engineering work to do this properly — embedded signing keys, signed manifests, a transport that does not depend on the server you are fetching from being the server you trust — is a quarter of work, not a one-letter change. The threat model was not "MITM on the update channel" on day 1; the threat model was "we do not pay for that." The 124 days, the embargo, the post-down request, the trivial patch — every step is consistent with the same threat model.

The fix is the same one the disclosure-policy-as-product community has been arguing for, applied in a place nobody usually looks: write the scope document first, with the threat model explicit, and design the program around it. If MITM is in the threat model, MITM is in the bounty. If MITM is not in the threat model, document that and accept the engineering cost of a separate mitigation. The current shape — MITM in the threat model, MITM out of the bounty — is the shape that produces a 124-day disclosure and a CRC-32 patch. Every large-vendor PSIRT that has shipped a desktop updater in the last ten years is currently in this shape. AMD is the one that got caught.

Disclosure

Drafted with AI assistance. Primary source: MrBruh, "The RCE that AMD wouldn't fix," 11 June 2026, https://mrbruh.com/amd2/. HN thread: https://news.ycombinator.com/item?id=48492215 (209 points, 91 comments at fetch time). Quoted material in the post is taken from the blog post and the HN thread; the technical details of the vulnerability (HTTP payload URLs in an HTTPS app.config, no signature verification, immediate execution of the downloaded binary) are MrBruh's static-analysis findings. The disclosure timeline — initial submission, Intigriti rejection as out of scope, the 87-day silence, the two-days-before-embargo patch notification, the 124-day total — is MrBruh's reconstruction from his own correspondence with AMD PSIRT. The CRC-32 detail in the patched binary is also from MrBruh's decompilation; AMD's own communication describes the patch as "signature verification," and the researcher's decompilation contradicts that framing. The "$0 paid out across Google, ASUS, AMD, TP-Link, MSI" figure is from the post's own "Donations" section. The "~10k USD if in scope" estimate is from the same section. The tptacek / amiga386 exchange on bug bounty program design is from the HN thread, not the blog post. The CVE number AMD will assign is not yet public; this post does not name a specific CVE.

Sources

MrBruh, "The RCE that AMD wouldn't fix," 11 June 2026 — https://mrbruh.com/amd2/
HN discussion, 209 points, 91 comments — https://news.ycombinator.com/item?id=48492215
MrBruh's first HN post on the same vulnerability, February 2026 — https://news.ycombinator.com/item?id=46906947
tptacek and amiga386 comments in the 48492215 thread (comment ids visible in the thread)
AMD PSIRT page (general) — https://www.amd.com/en/corporate/product-security
Intigriti bug bounty platform — https://www.intigriti.com/

Just another unique way to voice out.

Friday, June 12, 2026

AMD's AutoUpdate: The Bug Bounty Says It's Not a Bug