All posts
Gadgets & Hardware

AMD Denies $10,000 Bounty After Patching Critical Updater Flaw

Manaal Khan12 June 2026 at 4:17 pm5 min read
AMD Denies $10,000 Bounty After Patching Critical Updater Flaw

Key Takeaways

AMD Denies $10,000 Bounty After Patching Critical Updater Flaw
Source: Latest from Tom's Hardware
  • AMD patched a high-severity (CVSS 7.7) auto-updater vulnerability after 124 days but denied the researcher any bounty payment
  • The vulnerability allowed attackers to execute malicious code via man-in-the-middle attacks on unencrypted HTTP update downloads
  • Security researchers criticize AMD's fix for using checksums instead of proper digital signature verification

AMD has fixed a critical vulnerability in its auto-updater software but refused to pay the security researcher who discovered it. Paul, the independent researcher who identified the flaw, expected a $10,000 bounty for finding a remote code execution (RCE) class bug. Instead, AMD told him that man-in-the-middle attacks fall outside its bug bounty policy.

The vulnerability, now tracked as CVE-2026-40677, carried a CVSS severity score of 7.7, classified as "High." It took AMD 124 days from the initial report to release a fix. During that period, Paul cooperated fully with the company, even removing his public blog post at AMD's request.

124 days
Time from initial vulnerability report to AMD's public patch release, well beyond the industry-standard 90-day disclosure window

How the Vulnerability Worked

The flaw existed in how AMD's software downloaded updates. The updater fetched files over unencrypted HTTP instead of HTTPS, and it failed to verify the digital signature of downloaded binaries before executing them.

The updater was performing an insecure HTTP request to download an executable, and worse, it was not verifying the digital signature of the downloaded binary before executing it.

— Paul (MrBruh), Independent Security Researcher

This combination created a straightforward attack path. Anyone on the same network as the victim could intercept the update request and serve a malicious payload instead. The system would then automatically execute that payload with user privileges. No user interaction required beyond the auto-updater doing its job.

A Frustrating 124-Day Timeline

February 2025
Paul submitted the vulnerability report to AMD's bug bounty program. AMD rejected the bounty claim, citing that MITM attacks were out of scope.
February 2025
AMD requested Paul take down his blog post, promising a CVE, a fix, and attribution. Paul agreed.
March 2025
Paul proposed the industry-standard 90-day disclosure window. AMD requested more time, citing multiple affected tools.
May 2025
Paul agreed to a 100-day window and checked in with AMD before the deadline. AMD requested additional time again.
June 9, 2025
AMD released the fix, 124 days after the initial report. Paul republished his blog post.

AMD told Paul the delay was necessary because "multiple tools are affected by [the bug]" and that customers needed "additional time once [the fixes] are made available." Paul found this reasoning puzzling. As he noted, if the issue affected multiple tools and required customer coordination, that suggested it was serious enough to warrant compensation.

The fix itself raised eyebrows. Paul described it as essentially a one-character change, replacing "http" with "https" in the code. If the actual code change was that simple, the 124-day timeline becomes harder to justify.

The Fix May Not Be Enough

AMD has transitioned the updater to HTTPS, which encrypts the connection and makes man-in-the-middle attacks significantly harder. But security researchers remain concerned about what's still missing.

The patched version reportedly relies on basic checksums rather than cryptographic signature verification. Checksums confirm a file wasn't corrupted in transit. Digital signatures confirm the file actually came from AMD and wasn't tampered with by anyone along the way. These are different security guarantees.

For an auto-updater that runs with user privileges, digital signature verification is considered a baseline security practice. Microsoft, Apple, and most major software vendors sign their updates and verify those signatures before execution. Without that verification, a compromised CDN or certificate authority could still potentially serve malicious updates.

The Bug Bounty Policy Problem

AMD's decision to exclude this vulnerability from its bounty program has drawn criticism from the security community. The company's policy apparently treats man-in-the-middle attacks as out of scope, regardless of what the attacker can achieve through that vector.

This creates a strange situation. An RCE vulnerability discovered through other means would qualify for up to $10,000 under AMD's program. The same RCE vulnerability, requiring a MITM attack as the delivery mechanism, qualifies for nothing. The end result for victims is identical: an attacker running arbitrary code on their machine.

Discussions on Hacker News and Reddit's r/cybersecurity subreddit echoed this frustration. Many security professionals argued that an RCE-class vulnerability should always be in scope, regardless of the attack vector required to exploit it. The attack vector affects how easy or difficult exploitation might be, but it doesn't change the severity of what happens when exploitation succeeds.

This isn't an isolated incident. Microsoft has faced similar criticism over its handling of researcher reports. The pattern suggests a broader tension between how companies structure bug bounty programs and how security researchers expect responsible disclosure to work.

What AMD Users Should Do

If you use AMD's software, download the latest version. The patched auto-updater is included in AMD's current software pack. The HTTPS transition removes the most obvious attack path.

The vulnerability primarily affected users on shared or untrusted networks. Public Wi-Fi, corporate networks with malicious insiders, or compromised home routers all represented potential attack points. With the HTTPS fix in place, these scenarios become significantly harder to exploit, though concerns about the lack of signature verification remain.

Also Read
Novo Nordisk Breach Exposes Clinical Trial Patient Data

Another recent case of how companies handle security vulnerabilities and disclosure

Also Read
French Govt Tchap Breach Exposes 73,000 Civil Servant Accounts

Related security breach coverage for enterprise security context

ℹ️

Logicity's Take

Frequently Asked Questions

Is my AMD software vulnerable to this auto-updater bug?

If you download the latest version of AMD's software pack, you'll get the patched auto-updater that uses HTTPS. The vulnerability has been fixed as of June 9, 2025.

Why did AMD deny the bug bounty payment?

AMD's bug bounty policy excludes vulnerabilities that require man-in-the-middle attacks to exploit. Since this RCE flaw needed a MITM attack as the delivery mechanism, AMD considered it out of scope.

What is a man-in-the-middle attack on an auto-updater?

An attacker on the same network intercepts the update request between your computer and AMD's server, then sends a malicious file instead of the legitimate update. Your system then executes that malicious file.

Is the AMD auto-updater fix complete?

AMD switched to HTTPS for downloads, which is a significant improvement. However, security researchers note the fix uses checksums instead of cryptographic signature verification, which is considered a weaker security approach.

How serious was this AMD vulnerability?

The vulnerability received a CVSS score of 7.7, classified as High severity. It allowed remote code execution, meaning attackers could run arbitrary programs on affected systems.

ℹ️

Need Help Implementing This?

Source: Latest from Tom's Hardware

M

Manaal Khan

Tech & Innovation Writer

Related Articles