导语
10 月 22 日，开源 UEFI 固件项目 TianoCore 发布安全公告（GHSA-99cj-7hg9-mp4m），披露了一个潜伏约 16 年的缓冲区溢出漏洞 CVE-2026-97631，CVSS 评分 9.5。漏洞位于 EDK II 的 PXE 网络引导驱动中，攻击者只需在目标机网络引导的窗口期内发送一条精心构造的 ICMP 错误消息，就可能让代码在操作系统加载之前执行。对服务器和云基础设施运维来说，这类"固件层漏洞"的处置逻辑与普通补丁完全不同，值得认真读懂。
一、事件概述：一份迟到了 16 年的公告
CVE-2026-97631 位于 EDK II 的 NetworkPkg 网络组件中的 PXE Base Code 驱动（UefiPxeBcDxe），IPv4 与 IPv6 两条处理路径都存在边界计算错误。据 Ars Technica 等媒体报道，该缺陷由 Anthropic 与 Google 的研究人员发现，双方原本安排了明年 1 月的协同披露，但修复代码以公开 Pull Request 的形式提前出现，打乱了计划，TianoCore 遂于 10 月 22 日正式发布公告。
上游修复已于 10 月 15 日合入主仓库（PR #13302）。但需要特别注意：截至 10 月 28 日，官方公告中尚未列出包含该修复的 EDK II 稳定版本，各硬件厂商（OEM）需要把上游修复集成进自己的固件树、重新构建、验证后再发布 BIOS/UEFI 更新。这意味着大量已售出的服务器短期内仍处于"有修复代码、无成品固件"的状态。
二、漏洞原理：操作系统启动前的"真空期"
PXE（Preboot eXecution Environment）网络引导是数据中心批量装机的常用能力：服务器不从本地磁盘启动，而是从网络上的引导服务器拉取启动镜像。在引导过程中，EDK II 的 PXE 驱动会开放一个监听器接收 ICMP 错误消息，并把每条消息拷贝进一个固定 504 字节的字段。
问题就出在这个拷贝循环：无论是 IPv4 还是 IPv6 的处理函数，目标指针按"累计长度"而不是"分片长度"前进，而接收路径上没有任何环节对总长度做上限约束。攻击者向正在网络引导的机器 IP 发送单播 ICMP 错误消息，攻击者控制的字节就会写到缓冲区之外。轻则导致引导过程挂起（拒绝服务），重则溢出被"定向利用"为在 DXE（Driver Execution Environment）阶段执行任意代码——这是 ring 0 级别的固件权限。
关键在于时机：这一切发生在操作系统启动之前，Secure Boot、TPM 度量、EDR 和杀毒软件都还没有加载。传统安全软件对这一段引导过程基本是"失明"的。
三、影响范围：一个开源代码库，半个服务器市场
EDK II 本身不是某个厂商的私有代码，而是绝大多数 UEFI 固件的开源参考实现：AMI、Insyde、Phoenix 等固件厂商以它为基础构建产品，微软的加固分支 Project Mu 也包含同一组件。截至 edk2-stable202608（含 2026 年 9 月 14 日的主仓库状态）均受影响。发行版方面，Red Hat Enterprise Linux 8/9/10 的 edk2 包受影响，SUSE 与 Debian 在公告发布时尚未提供修复（Debian 安全跟踪器中 bookworm、trixie、forky 相关包均列为未修复）。
落到实际资产上：只要机器启用了 PXE 网络引导——包括大量数据中心服务器、云主机、存储设备和部分工作站——就暴露在风险窗口内。多个信息来源口径一致的是：仅从本地磁盘启动、未启用网络引导的系统不受该漏洞影响。
四、为什么它比普通漏洞更棘手
第一，固件层持久化，重装系统也未必干净。如果攻击者在 DXE 阶段植入代码，重装操作系统、更换系统盘都未必能清除——这正是 MITRE ATT&CK 中 T1542.001（系统固件持久化）的典型场景。
第二，攻击者在这个阶段还能碰到 TPM。Dragos 首席研究官 HD Moore 在接受 Ars Technica 采访时指出，引导流程此时仍可访问 TPM 等敏感部件，破坏磁盘加密是一个很现实的攻击用途。
第三，供应链属性放大了修补难度。一个上游缺陷要经由数千个 OEM 固件树各自集成、验证、发布，任何一家厂商动作慢，它的客户就继续暴露。这起事件也被合规视角反复引用：NIST SP 800-53 的 SI-2（缺陷修复）与 SA-12（供应链保护）、CISA 零信任成熟度模型中的"设备健康与固件完整性证明"——如果固件层可在健康校验之前被攻破，设备可信的根基就被动摇了。
第四，有前车之鉴。2024 年初的 PixieFail 同样是 EDK II 网络协议栈的一批漏洞；此后社区开展的模糊测试活动，依然漏掉了这个存在 16 年的缺陷。
五、攻击门槛：不是"一键打全网"，但别因此放松
需要把风险说准确：这不是一个可以对着互联网随意扫描利用的漏洞。利用它需要三个条件同时成立——攻击者位于目标的相邻网络、目标恰好处于 PXE 引导的短暂窗口期、并且利用代码需要针对具体机型、固件版本和配置调整内存地址。Eclypsium 首席研究员 Jesse Michael 对 Ars Technica 表示，这类利用必须"一机一调"，无法盲目地面向整个机群扫射。
此外，载荷本身不会自动持久化，但运行一次就足以种下持久的后门。截至本文发稿，公开渠道未见该漏洞的在野利用报告，也未见到公开利用代码；具体情况以 CISA/NVD 及各厂商后续公告为准。但对于批量装机、大面积使用 PXE 的数据中心和云服务商来说，"门槛高"不等于"可以等"。
六、排查思路：先回答三个问题
1. 哪些机器启用了 PXE/网络引导？排查范围包括物理服务器的 BIOS/UEFI 设置、带外管理卡引导选项，以及批量装机、无盘工作站、自动化置备流程。
2. 固件来自哪家 OEM，厂商有没有动作？到服务器或主板厂商的支持页面检索是否出现提及 CVE-2026-97631 的 BIOS/UEFI 更新；自建或使用 EDK II 衍生固件的环境，则需跟踪上游稳定版发布。
3. 有没有启动链的"健康基线"？如果环境中有 TPM PCR 远程证明或启动度量监控，把固件相关度量值纳入基线，异常变化就是最直接的失陷信号。
七、修复与缓解建议（以官方公告为准）
不需要网络引导的机器：直接关闭。在固件设置中禁用 PXE/网络引导，同时关闭不用的 UEFI 网络栈——多个来源确认仅本地磁盘启动不受影响，这是零成本消除攻击面的做法。
依赖 PXE 批量装机的环境：收敛引导流量。把 PXE 引导限制在独立、可信的置备 VLAN 内，不要与办公网、生产网混排；在边界设备上对指向引导主机的异常 ICMP/ICMPv6 错误消息进行过滤。
固件更新：盯紧厂商渠道。上游修复（PR #13302）已于 10 月 15 日合入，但成品固件取决于各 OEM 的发布节奏；Red Hat、SUSE、Debian 等发行版的 edk2 包更新也需分别跟踪。
刷写固件是高风险操作，务必按保守流程来：先在测试机上验证更新包；操作前备份现有固件与配置；安排维护窗口；严格按厂商说明执行，不要在未验证的生产机上直接批量刷写——刷写失败可能导致机器无法启动。
加强监控。对启用 PXE 的环境，关注引导链度量（TPM PCR）的异常变化与引导异常中断事件，作为事中检测手段。
本文仅做风险解读，不涉及任何攻击性细节；具体补丁版本与处置方式，一律以 TianoCore 官方公告和各 OEM 发布页面为准。
八、后续观察
接下来值得留意的几件事：一是 EDK II 何时发布包含修复的稳定版；二是各家 OEM 与云厂商固件更新的落地进度；三是是否出现公开利用代码或实际攻击报告。对运维团队而言，本周就可以推进的动作很明确：盘点 PXE 使用面、关闭不必要的网络引导、把必须保留的引导流量收拢进隔离的置备网络。固件层的安全欠账，从来都是早发现早处理，而不是等固件更新推送上门。
暂无评论内容