一场由烦人弹窗引发的安全发现
作者在组装新游戏 PC 后，被一个周期性弹出的命令提示符窗口频繁打断。经过追踪，发现罪魁祸首是 AMD 的 AutoUpdate 自动更新软件。带着一肚子火，作者决定通过反编译来弄清楚这个软件到底在干什么——结果意外发现了一个极其简单的 远程代码执行（RCE）漏洞。
漏洞细节：HTTP 而不是 HTTPS
首先，作者发现 AMD AutoUpdate 将更新 URL 存储在程序的 app.config 文件中。虽然生产环境使用了名为"Development"的奇怪 URL，但好歹走的是 HTTPS，看起来没什么问题。
真正的漏洞在于：当你用浏览器打开这个 XML 配置 URL 时，会发现里面列出的所有可执行文件下载地址全是 HTTP，而非 HTTPS。
这意味着：同一网络中的恶意攻击者，或者能访问你 ISP 的国家级对手，可以轻松实施 MITM（中间人攻击），将网络响应替换为任意恶意程序。
作者本以为 AMD 至少会有证书验证机制来防止执行未签名程序，但反编译结果令人震惊——AutoUpdate 完全不做任何验证，下载后直接执行。
漏洞报告：一场长达 124 天的拉锯战
作者将漏洞报告给 AMD，却陷入了一场旷日持久的扯皮：
2026-01-27 — 发现漏洞
2026-02-06 — 报告漏洞，当天被 AMD 标记为"范围外/不修复"
2026-02-07 — 帖子在 Hacker News 爆火后，AMD 改变态度表示会调查
AMD PSIRT 联系作者称："即使 Intigriti（AMD 的第三方漏洞赏金平台）将其标记为超出范围，我们仍然愿意审查详情。"但他们要求作者在修复前下架博客文章。
作者同意了——后来他反思这是错误的决定。
报告被标记为范围外的理由是：影响的是可选工具（非核心产品），且攻击场景依赖 MITM。不过 AMD 内部审核后决定：发布 CVE、实施修复、给予安全研究员致谢——但不支付赏金。
124 天只为加一个字母
作者询问披露时间线，行业标准是 90 天。AMD 声称因为多个产品受影响，需要更长的 embargo（禁运期）。然而修复方案本身简单到令人难以置信——只需在 XML 配置文件的 HTTP URL 上加一个 "s"（变成 HTTPS）。
作者等待了 87 天后再次询问，AMD 在此期间没有主动更新进展。最终 AMD 在 embargo 结束前几天才告知修复方案：将 Ryzen Master 的自动更新从安装程序移到应用层，所有通信改用 HTTPS，并增加签名验证。
作者验证后发现：HTTPS 确实启用了，但签名验证是假的——他们只对下载的可执行文件做了 CRC-32 校验，这在密码学上毫无安全性可言。
最终，从初次披露到公开修复，整整花了 124 天——只为让 AMD 给几个 HTTP URL 加上 "s"。
黑色幽默：自动更新器本来就坏了
整件事中最讽刺的部分是：AMD 的自动更新器因为一个完全无关的 bug，本来就处于报废状态。AMD 将软件包列表从 ati.com 迁移到了 drivers.amd.com，但 AutoUpdate 程序无法处理 HTTP 重定向，直接崩溃或卡死。
这意味着作者发现的 RCE 漏洞实际上 根本无法利用——因为更新程序在到达那段漏洞代码之前就已经崩溃了。一个经典的"第 22 条军规"：要修复漏洞必须先更新更新器，但更新器在重定向 bug 修复前根本无法更新。
作者建议所有安装了 AMD 软件的用户：彻底卸载所有 AMD 软件，然后从官网重新下载最新版本。
结语：安全研究员的困境
作者迄今为止向 Google、ASUS、AMD、TP-Link、MSI 等公司报告的漏洞，总共获得的赏金为 0 美元。AMD 这个漏洞如果在范围内，本可获得约 10,000 美元赏金。
