CVE-2026-97631：UEFI 固件漏洞怎么排查

看到 Hacker News 和 Ars Technica 关于“威胁地球上大多数服务器”的标题，不能把“多数服务器使用 UEFI”直接翻译成“多数服务器都能被远程拿下”。按目前公开披露，应该优先排查的是使用相关 EDK II ICMP 组件、启用 PXE 及相关功能，并且攻击者已经取得目标网络一定控制条件的设备，而不是盲目给所有 UEFI 服务器贴上“已中招”标签。

实际处置顺序很明确：先收集厂商、型号和固件构建号，再用这些信息匹配厂商公告；确认受影响后，优先安装对应的 BIOS/UEFI 更新。暂时没有补丁且业务允许时，可以限制或停用 PXE 及启动网络访问，但只能算临时收敛暴露面，不能代替固件修复。本文依据公开披露和厂商表态整理，未进行漏洞复现；现有资料也没有提供适用于所有设备的扫描命令、真实输出、OEM 公告编号或统一菜单路径，因此不编造这些内容。

9.5 分不等于所有 UEFI 服务器都能被直接拿下

9.5 分说明的是成功利用后的风险等级，不是每台设备都能无条件触发漏洞。公开报道将 CVE-2026-97631 定位在开源 TianoCore EDK II 的 ICMP 组件中，属于内存破坏类缺陷。攻击者如果成功利用，可以在操作系统和安全机制加载前执行恶意代码，并进入 CPU 的 ring 0 最高特权级。

这里还要分清 UEFI 规范与具体实现。UEFI 是固件架构规范，实际实现通常存放在主板的闪存芯片中；TianoCore EDK II 又是被大量供应商复用的实现基础，因此排查时必须区分规范、实现和具体固件版本。 但“设备支持 UEFI”不能直接推出“这台设备包含漏洞代码”，“厂商采用 EDK II”也不能直接推出“当前固件版本一定受影响”。最终仍需核对具体实现、固件构建号和 OEM 公告。

严重度高也不等于已经出现大规模利用。报道发布时尚未发现实际攻击案例，而且攻击者需要先取得目标网络的一定控制权。 因此，新闻标题适合用来提高排查优先级，不适合直接写成“全球服务器已经失守”。

搜索结果里还经常混入另一则“23 个 InsydeH2O 高危漏洞”的报道。那是另一组主要涉及 SMM 的漏洞，评分范围、产品和补丁路径都与 CVE-2026-97631 不同，不能把两组漏洞的受影响机型、构建号或处置结果放在一起。

先核对 PXE、固件版本和厂商公告

目前没有可靠的通用命令可以“扫出 CVE”，排查应从资产匹配开始。UEFI 固件通常位于设备自身的闪存中。是否包含特定缺陷、实现方式和功能开关因厂商及型号而异，当前没有可靠依据支持用一条操作系统命令判断所有设备是否受影响。 现阶段按以下四步匹配资产。

第一，建立固件资产清单。至少记录 厂商、型号或 SKU、CPU 架构、BIOS/UEFI 版本、构建号、PXE 状态、相关功能状态、启动网络可达范围、对应公告编号 和 修复构建号。这些字段应尽量来自现有资产台账、管理员记录和设备管理信息；没有数据的字段应标为未知，不能直接当作“不受影响”。

第二，用“厂商＋型号＋固件构建号＋公告编号”匹配 OEM 公告。公开报道提到，英特尔表示其处于安全支持期内的商用产品不受影响，Arm 也表示该漏洞不直接适用于其产品组合。 这两项表态都必须按具体 SKU 和支持状态复核，不能扩展为“所有英特尔或 Arm 设备都安全”。其他厂商、停止支持的产品以及定制固件，更不能套用这些结论，只能以对应制造商公告和修复版本为准。

第三，单独确认 PXE、相关功能及启动网络的访问范围。报道描述的主要利用路径与 PXE 启动及启用相关功能有关，因此这些设备应排在前面。 但网络可达不等于“一键攻破”，攻击者仍需要一定的前置网络控制条件。这一步查到的是“是否具备暴露路径”，不是“是否已经被入侵”；版本排查本身无法证明设备历史上没有被利用。

第四，更新后重新核对构建号、厂商公告和 PXE 配置。验证标准应当是更新后的固件构建号与公告指定的修复版本一致，而不只是更新工具显示执行成功。如果 OEM 提供了官方检测工具，应按其支持的系统和版本补充检测；没有官方工具时，不应把自行拼出的固件信息命令包装成漏洞扫描器，也不应虚构扫描结果。

真正的修复是更新对应 BIOS/UEFI

正式修复路径仍然是从设备制造商取得并安装对应的 BIOS/UEFI 更新。 操作时应按精确型号和公告选择更新包，先在同型号测试设备上验证启动及业务依赖是否正常，记录当前构建号与配置，并安排维护窗口后再分批部署。厂商如果提供回滚方案，应按官方说明准备；不要拿其他型号或来源不明的固件交叉刷写。

设备尚未收到补丁，或者暂时无法重启时，可以在业务允许且厂商允许的前提下，限制或停用 PXE、相关功能以及启动网络访问。这能收敛报道所称主要利用路径的暴露面，但可能影响无盘启动、部署和恢复流程，所以必须先确认相关依赖，不能把关闭功能当成无副作用的永久方案。

操作系统更新、重新安装系统或者单靠 Secure Boot，都不能替代这次固件更新。厂商给出的修复路径是更新 BIOS/UEFI；保留其他安全控制可以降低整体风险，却不能修复存在缺陷的 ICMP 组件。

对于已经有异常启动、异常网络通信或其他可疑迹象的设备，还需要单独进入事件响应流程。固件更新用于修复当前构建中的缺陷、降低后续风险，但不等于完成历史入侵的取证与清除；构建号匹配正常，也只能说明当前构建处于公告给出的修复范围。

我的判断是：9.5 分足以让 PXE 密集使用的数据中心立即行动，但正确顺序是“厂商公告匹配资产清单，再做定向固件更新”，而不是宣布所有服务器失守，也不是用批量重装系统代替补丁。