AMD refused $10,000 bounty to researcher Paul LaRosa despite fixing HTTP vulnerability in Windows auto-updater
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.
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.
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.
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.