AMD 这次的问题，卡在一个很具体的地方：AutoUpdate 的配置入口是 HTTPS，但 XML 里给出的可执行文件下载地址却是 HTTP。

研究员称，程序会下载并执行这个文件，且没有有效的密码学签名校验。只要攻击者已经具备中间人攻击能力，就可能替换下载内容，让更新器执行恶意程序。

前提要说清。它不是任意互联网远程打穿 AMD 电脑。攻击者需要能控制或篡改用户网络流量，比如同一局域网、恶意 Wi-Fi、被劫持的网络路径，或更高层级的链路能力。

我更在意的是后半段：AMD/Intigriti 起初把它判为 out of scope，理由是可选工具且依赖 MITM；后来 AMD 又回头审查、修复、发 CVE，并在 124 天后解除披露限制。

这就不是单个漏洞有多刺激的问题了。它更像一次边界测试：可选工具的更新器，能不能因为“可选”就被放低安全标准？

问题出在更新链路下游，不在入口那一眼

研究员看到的第一层配置并不离谱。AutoUpdate 的 app.config 指向 HTTPS XML，看起来像是安全的。

问题在下一跳。XML 里列出的可执行文件 URL 使用 HTTP。反编译代码还显示，程序下载文件后会执行。

这条链路只要有一环允许被替换，更新器就会从“修补工具”变成“投递入口”。软件更新器天然敏感，因为它做的事就是下载、安装、执行。入口是 HTTPS，不等于全链路可信。

环节研究员发现AMD 后续说法我的判断
配置入口app.config 指向 HTTPS XML未否认入口安全不等于下载安全
下载链接XML 中可执行文件使用 HTTP改为 HTTPS这是必要修复
文件校验作者称未见有效签名验证AMD 称加入校验仍需说明校验机制
利用前提需要 MITM 能力未披露实战利用案例不能写成大规模入侵
更新器状态重定向可能导致崩溃或卡死原文未给出完整修复细节可能影响实际可利用性，也影响自我修复

这里还有一个反转。原文提到，AutoUpdater 可能因为 AMD 将软件包列表从 ati.com 迁移到 drivers.amd.com 后无法处理重定向，出现崩溃或卡死。

这会降低部分环境里的实际可利用性。漏洞代码路径未必总能走到“下载并执行”。

但这不是好消息。更新器如果连重定向都处理不好，用户也可能无法依赖它拿到修复。补丁之门先坏了，这是更新系统最尴尬的状态。

AMD 最终称，Ryzen Master 的自动更新功能已从安装器移到应用层，更新通信改为 HTTPS，并加入校验。研究员确认 HTTPS 已生效，但质疑所谓“签名校验”实际只是 CRC-32。

CRC-32 不是密码学签名。它适合发现传输错误，不适合防恶意篡改。若 AMD 的校验确实停在 CRC-32，这个修复至少在安全表述上过宽。

赏金可以不付，产品安全不能当没事

这次时间线也很关键。

研究员在 2026 年 2 月 6 日提交报告。同日，AMD 使用的第三方赏金平台 Intigriti 将其关闭，理由是影响可选工具，且 MITM 场景不在范围内。

2 月 7 日，AMD PSIRT 又回头表示继续内部审查，并要求研究员撤下已发布的博客。到 6 月 9 日，披露限制解除。前后 124 天。

日期动作说明
2026-02-06研究员提交报告，随后被关闭初始 triage 按赏金范围处理
2026-02-07AMD PSIRT 表示继续审查厂商承认问题仍有安全审查价值
2026-06-09embargo 结束披露周期达到 124 天

厂商设赏金范围，本身没问题。不是所有安全问题都能拿钱，也不是所有报告都该走同一优先级。

但“不发赏金”和“不修漏洞”是两件事。更新器属于软件供应链的一部分。哪怕 Ryzen Master、AutoUpdate 是可选工具，它们也运行在用户机器上，并承担安装更新的角色。

AMD 后来的解释也不是完全站不住脚。原文线索里提到，多个可选工具可能受影响，发布需要排期，也要给客户留出审查修复的时间。企业客户、OEM、驱动工具链，确实可能牵涉兼容性。

问题是，124 天仍然偏长。尤其当核心修复包括把 HTTP 下载改为 HTTPS 时，外部很难判断到底是修复复杂，还是流程拖慢。

目前还看不清具体受影响版本、受影响用户数量，也没有证据表明漏洞已被大规模利用。能确定的是，初始关闭、随后审查、长期 embargo 这三步放在一起，会让研究员很难判断厂商到底把问题放在什么优先级。

两类人该怎么处理：别恐慌，也别等旧更新器自救

最相关的不是所有 AMD 用户，而是两类人。

一类是安装过 Ryzen Master、AutoUpdate 或相关 AMD 可选工具的高级 PC 用户。另一类是安全研究员和做漏洞披露流程的人。

对象这件事意味着什么更稳妥的动作
安装 AMD 工具链的高级 PC 用户风险依赖 MITM，不等于马上会被攻击；公共 Wi-Fi、校园网、酒店网络、公司访客网络下风险更高不依赖旧 AutoUpdate 自行修好自己；从 AMD 官网重新下载新版工具；必要时卸载旧组件后安装
安全研究员与披露从业者out of scope 不代表没有产品安全价值；平台 triage 和厂商 PSIRT 判断可能不一致报告里明确写出利用前提、影响链路、可复现证据；遇到关闭时保留沟通记录，要求厂商给出安全判断而不只是赏金判断

对普通用户，最不该做的是恐慌。这个漏洞需要 MITM 条件，没有公开证据显示它已被大规模利用。

但如果你装过相关 AMD 工具，又经常在公共网络里使用电脑，处理成本并不高：去 AMD 官网拿新版，别指望旧 AutoUpdate 自己完成迁移。旧更新器是否稳定、是否能处理重定向，本身就是这次争议的一部分。

对披露从业者，这个案例的提醒更现实：报告不要只写“可 RCE”。要把前提写死，把攻击链写短，把边界写清。

MITM 是限制条件，不是免责条款。可选工具是分发位置，不是安全豁免。

接下来最该看三件事：AMD 是否公开说明所谓校验到底是不是密码学签名；哪些可选工具和版本受影响；旧版 AutoUpdate 用户有没有可靠迁移路径。

如果这些问题不给清楚，CVE 编号只能说明漏洞被记录过，不能说明更新链路已经重新变得可信。