AMD 远程代码执行漏洞曝光
博主新游戏电脑上，一个烦人的控制台窗口时不时弹出，多次打断操作。最终追踪到，罪魁祸首是 AMD 的自动更新软件。博主对该软件进行反编译，意外发现一个简单的远程代码执行（Remote Code Execution，RCE）漏洞。
漏洞细节与风险
首先，AMD 将更新 URL 存储在程序的 `app.config` 中，虽在生产环境中使用“开发”URL 有点奇怪，但因使用 HTTPS，还算安全。然而，当在浏览器中打开 `.xml` URL 时，会发现所有可执行文件的下载 URL 都使用的是 HTTP。这意味着，网络中的恶意攻击者，或者能够访问网络服务提供商（ISP）的国家级黑客，都可以轻松实施中间人（MITM）攻击，将网络响应替换为他们选择的任何恶意可执行文件。
向 AMD 报告漏洞遇阻
博主发现问题后，向 AMD 报告了该漏洞。不幸的是，他们漏洞奖励计划的服务条款明确规定，中间人攻击不在该计划范围内，因此报告被关闭。不过，在文章在 Hacker News 上引发关注后的一天内，AMD 联系了博主，表示会重新调查此事。
AMD 处理态度与后续要求
AMD 产品安全事件响应团队（PSIRT）表示仍在对报告进行内部审查，即便 Intigriti 以不在奖励计划范围内为由拒绝了提交，他们仍愿意审查细节。同时，他们要求博主在问题修复之前删除博客文章。博主同意了该要求，但后来认为这是个错误的决定。
AMD 最终决定与披露情况
经过进一步内部审查，AMD 决定为此漏洞分配一个 CVE 编号、实施修复、对安全研究人员进行表彰。但他们以该漏洞影响可选工具且依赖中间人攻击场景为由，不支付奖励。此外，他们要求博主在比行业标准更长的时间内保持文章删除状态，解释是该问题可能影响多个软件产品。然而，修复这个问题可能只需要在他们托管的 XML 文件中的 HTTP URL 后面加一个 `s`。
漫长等待与修复情况
从披露漏洞开始，博主等了 69 天，总共等了 87 天才再次联系 AMD。博主表示不能无限期等待，计划在首次披露 100 天后重新发布报告。尽管 AMD 保证会及时更新进展，但实际上并未主动告知情况，直到保密期快结束的前几天，才告知漏洞的修复方案。
意外情况：更新程序无法使用
根据原帖在 Hacker News 讨论区里的一个链接，由于另一个完全不相关的原因，自动更新程序已经完全无法使用了。AMD 曾将软件包列表的托管地址从 ati.com 切换到了 drivers.amd.com，自动更新程序无法处理这种重定向，导致程序崩溃或卡死。这意味着博主发现的漏洞实际上无法被利用，还造成了两难局面：需要更新更新程序来修复漏洞，但更新程序在重定向问题解决之前无法更新。
最终更新：修复方案仍有问题
在保密期快结束的前几天，AMD 告知博主他们对漏洞的修复方案：在 Ryzen Master 中，自动更新功能已从安装程序中移除，并移至应用层；在应用程序内部，所有更新通信都使用 HTTPS 进行加密，并且更新会进行签名验证。博主验证后发现，虽然现在确实完全使用了 HTTPS，但关于签名验证的说法并不属实，他们只是对下载的可执行文件进行了 CRC - 32 检查，这在加密层面并不安全。
捐赠与时间线
博主向谷歌、华硕、AMD、TP - Link、微星等公司报告的漏洞，获得的奖励总额为 0 美元。如果 AMD 的这个漏洞在奖励范围内，本可以获得约 1 万美元的奖励。时间线如下：2026 年 1 月 27 日发现漏洞；2026 年 2 月 6 日报告漏洞，漏洞被标记为“不修复/不在范围内”，博客发布；2026 年 2 月 7 日 AMD 改变态度，表示会重新调查；2026 年 6 月 9 日，经过 124 天，漏洞保密期结束。那么，AMD 后续是否会进一步完善修复方案，保障用户安全呢？
