AMD Stiffs Researcher $10,000 Bug Bounty After Critical Security Flaw, Takes 124 Days to Fix

AMD refused $10,000 bounty to researcher Paul LaRosa despite fixing HTTP vulnerability in Windows auto-updater

Al Landes Avatar
Al Landes Avatar

By

Image: Deposit Photos

Key Takeaways

Key Takeaways

  • AMD’s auto-updater downloaded software via insecure HTTP, enabling malware injection attacks
  • Company refused $10,000 bounty payment despite acknowledging the critical remote code execution flaw
  • Fix took 124 days but still uses weak CRC32 validation instead of cryptographic signatures

Finding a critical security vulnerability should get you rewarded, not stiffed. AMD’s auto-updater was downloading software over insecure HTTP connections, letting network attackers slip malicious code onto your system during routine updates. The researcher who found this remote code execution flaw expected a $10,000 bounty. Instead, AMD fixed the problem after four months and paid nothing.

The Flaw That Could Own Your System

A trusted update process became an open highway for malware delivery.

Paul LaRosa discovered that AMD’s Windows auto-updater—used by Ryzen Master and other utilities—was grabbing updates through unencrypted HTTP connections. Anyone positioned on your network could perform a man-in-the-middle attack, swapping legitimate driver downloads with malware. Think of it like ordering food delivery but letting strangers intercept and replace your meal between the restaurant and your door. Your system would happily install whatever the attacker served up, believing it came from AMD.

This affects you if you’ve used AMD utilities that handle automatic updates. The vulnerability created a highway for attackers to achieve remote code execution, essentially gaining control of your machine through what should be a trusted update process.

Four Months of “Just a Little More Time”

What started as a 90-day disclosure window stretched into a four-month waiting game.

AMD acknowledged the flaw was real but refused the bounty, citing policy exclusions for man-in-the-middle attacks. The company asked LaRosa to delay public disclosure in February, promising a fix within 90 days—standard practice in security research. Then AMD asked for more time. Then more again. The final patch arrived 124 days after the initial report.

Compare that timeline to security best practices: critical vulnerabilities should be patched within 5-14 days, not over four months. It’s like your doctor finding cancer and scheduling treatment for next season. Some flaws demand urgency, especially those affecting automatic update mechanisms that users trust to keep them secure.

Still Using Weak Security After the “Fix”

The patch solved one problem but left deeper security weaknesses untouched.

AMD reengineered the auto-updater to use encrypted downloads, but the fix reveals deeper problems. The updated software still validates downloaded files using CRC32—a checksum that’s about as secure as a screen door. Modern software should use cryptographically signed updates that can’t be forged, not checksums that determined attackers can manipulate.

This case exposes how major vendors handle security: fix the immediate problem, avoid paying researchers through policy loopholes, and leave underlying weaknesses in place. You’re left wondering which other “secure” auto-updaters are similarly vulnerable, and whether companies care more about their bug bounty budget than your system security.

Share this

At Gadget Review, our guides, reviews, and news are driven by thorough human expertise and use our Trust Rating system and the True Score. AI assists in refining our editorial process, ensuring that every article is engaging, clear and succinct. See how we write our content here →