UEFI 高危漏洞 CVE-2026-97631 曝光：潜伏约 16 年，PXE 启动设备需关注固件修复

据 IT之家 10 月 29 日报道，开源 UEFI 参考实现 TianoCore EDK II 被披露存在高危漏洞 CVE-2026-97631，CVSS 4.0 评分为 9.5 分。问题位于 PXE 网络启动相关驱动，代码可追溯至约 2010 年。攻击者在特定条件下，可能于操作系统加载前执行恶意代码。由于 EDK II 被多家固件供应商采用，使用相关组件的服务器及其他设备需要关注后续修复。

漏洞如何触发：网络启动驱动缺少长度限制

根据 TianoCore 当地时间 10 月 22 日发布的安全公告，问题出在 PXE Base Code 驱动 NetworkPkg / UefiPxeBcDxe 处理 ICMP 错误报文的过程。相关实现会将接收的数据复制到固定大小为 504 字节的缓冲区，却没有正确限制复制长度，超长数据因此可能越界覆盖相邻内存。

当目标设备通过 PXE 进行网络启动时，攻击者若能向其发送特制 ICMP 错误报文，就可能触发该问题。成功利用可能带来任意代码执行；即使无法取得控制权，也可能造成启动异常或中断。但触发溢出不等于必然控制设备，代码执行还需要针对具体固件环境进行适配。

• 风险入口是受影响的 PXE 网络启动组件，并非所有设备的日常网络通信。
• 攻击者需要在设备进行 PXE 启动期间，具备向其发送相应报文的条件。
• 仅从本地硬盘或 SSD 启动，且不使用受影响网络启动组件的设备，不属于上述攻击场景。

影响解读：操作系统防护之外，固件供应链仍是关键

这类漏洞值得关注，核心在于其发生时机：攻击可能发生在操作系统及其安全防护机制加载之前。来源显示，恶意代码可能在安全启动（Secure Boot）和度量启动完成相关校验前执行，因此不能仅依赖这些机制防御本次攻击。这并不意味着所有安全启动方案都已失效，而是说明启动链中的底层代码也需要独立维护。

EDK II 是众多硬件厂商构建 UEFI 固件的代码基础，AMI、Insyde、Phoenix 等供应商采用相关实现，微软 Project Mu 也使用相关组件。不过，采用同一代码基础，不代表所有产品都受影响。实际风险仍取决于设备固件版本、组件配置，以及是否启用了相关 PXE 功能。

对于使用服务器集群、集中装机或网络部署流程的团队，这次披露提醒运维人员：资产安全清单不能只覆盖操作系统和应用，也应纳入固件版本与网络启动配置。AI 算力基础设施同样如此，但不能据此推定某款 AI 服务器已经受到影响。

修复进展：上游已合并，设备更新仍需跟进

TianoCore 已于 10 月 15 日将修复合并至 EDK II 上游主分支，但截至来源报道时尚未纳入稳定版本。红帽安全公告还将 RHEL 8、RHEL 9 和 RHEL 10 中的 edk2 软件包列为受影响，具体修复状态仍需继续跟踪。

对设备使用方而言，上游修复不等于整机固件已完成更新。更实际的做法是核查 PXE 使用情况，结合厂商公告确认受影响型号和版本，并按维护流程安排更新；不需要的网络启动功能，也可结合业务需求评估是否关闭。