全球绝大多数服务器受此固件代码执行漏洞威胁

全球各地的防御者再次面临应对代码执行漏洞的重担，这次的问题出在大多数全球服务器厂商和数据中心使用的启动固件中——这已是“又一次”漏洞响应。

该漏洞的严重程度评分高达9.5/10，存在于TianoCore EDK II 中。EDK II 是一个开源代码库，硬件制造商和云服务商用它来创建在启动序列中运行的 UEFI 固件。去年，UEFI 论坛的一位代表称EDK2 是“UEFI 规范的顶尖解决方案/实现”。几乎所有 UEFI 供应商（有时仍被称为 IBV 或独立 BIOS 厂商），包括 AMI、Insyde 和 Phoenix，都大量使用这些参考代码。微软的加固版 EDK2 分支 Project Mu 也使用了包含该漏洞组件的代码。

该漏洞被记录为 CVE-2026-97631，是 ICMP 组件中的一个内存损坏缺陷。攻击者可利用它执行恶意代码，这些代码在操作系统和固件实施 Secure Boot 等防御措施之前运行。Secure Boot 会为所有在启动过程中加载的代码（包括 Trusted Platform Module，即 TPM）建立信任链。虽然通过 CVE-2026-97631 传递的最终载荷没有持久性——意味着它们只运行一次——但它们可以为攻击者提供一个宽阔的窗口，用于安装其他载荷，这些载荷同样会在启动过程早期每次运行时执行。

祸水已出笼

发现 CVE-2026-97631 的两方——Anthropic 的 Alex Matrosov 和 Google 的 Dan Holmes——原本约定将该漏洞保密，直到原定于明年 1 月的协同披露。但主板及其他硬件制造商 AMI 上个月发布了一份 pull request，详细描述了该漏洞并附上代码修复。发现方注意到这份 PR 后，TianoCore 项目成员于上周发布了公开安全通告。

补丁代码已经公开，高级黑客想要弄清漏洞的触发方式并打造可用的 exploit 并非难事。更紧迫的是，这个 UEFI 漏洞影响数以百万计的终端设备，这些设备由数千家硬件厂商和云服务提供商销售和使用，要为它们打补丁既繁琐又耗时。而这已经是六天内第二次披露事故——上一次涉及 PHP 编程语言中的一个严重代码执行漏洞。

“EDK2 网络栈中这个 ICMP 解析器漏洞的有趣之处在于，它对信任链和整个生态的影响，” Metasploit 的缔造者、安全公司 Dragos 首席研究官 HD Moore 表示，“意图攻击附近终端或服务器的攻击者，可以利用这个漏洞在启动流程仍能访问敏感组件（比如终端的 TPM）的阶段劫持程序执行流。在攻击者拥有短期网络访问权限的场景下，这可以用来破解磁盘加密（如果是设备失窃，那就更容易了）。”

CVE-2026-97631 是 PXE 基础代码驱动（NetworkPkg/UefiPxeBcDxe）中存在的一个长达 16 年的缓冲区溢出漏洞。该驱动负责让服务器、存储设备及其他硬件通过下载本地网络代码来启动。在这个被称为预执行环境启动的过程中，驱动使用网络监听器来监控 ICMP 错误。由于驱动未强制执行 504 字节的内存拷贝限制，内部威胁者或已获得本地网络底层访问权限的黑客可以发送一条错误消息，将代码追加到该限制之外。随后，在 CPU 上运行的 UEFI 模块就会被破坏。

正如官方安全通告所述：

在网络启动期间，PXE 基础代码驱动（NetworkPkg/UefiPxeBcDxe）保持一个接收请求开放，用于处理 ICMP 错误消息，并将每条收到的消息复制到其私有上下文结构中固定的 504 字节字段 Mode.IcmpError。拷贝循环的边界处理在 IPv4 和 IPv6 处理程序中均存在错误（PxeBcIcmpErrorDpcHandle 和 PxeBcIcmp6ErrorDpcHandle）：对于超过 504 字节的消息，系统仍会继续拷贝字节；同时，目标指针按照累积长度而非单个片段长度进行推进，导致超尺寸消息将攻击者控制的字节写入字段之外。在接收路径的早期阶段，没有任何机制限制消息长度。

只要是在 PXE 启动序列期间，攻击者就能通过从任意网络距离向目标设备 IP 地址发送简单的单播数据报来投递恶意错误包。攻击者可以通过导致启动序列挂起来实施拒绝服务攻击。当攻击者知晓目标固件的具体构建版本时，还可以植入一个“伪事件”，使其恶意代码在 CPU 的 UEFI 固件环境中执行。该代码在 ring 0 运行，这是 CPU 的最高特权执行级别。由于此类漏洞利用可绕过旨在向远程服务器密码学证明硬件安全性的认证流程，因此为提升有限权限提供了关键机会。

又一个永恒的难题

CVE-2026-97631 加入了一份漫长的清单，记录着此前在 UEFI 或与其密切相关的代码中发现的诸多漏洞。其中后果最严重的当属 LogoFail，它源于几乎所有硬件厂商 UEFI 中嵌入的 Logo 图像。渲染漏洞允许攻击者破坏 UEFI 强制执行的信任链，进而在操作系统加载或 Secure Boot 运行之前植入恶意组件。PixieFail 则是一个与 CVE-2026-97631 类似的漏洞，同样源自 EDK2 中缺陷的 PXE 启动机制。在发现该漏洞后，研究人员启动了多个模糊测试（项目），旨在挖掘开源代码库中的其他关键缺陷。但事实证明，这些努力未能发现最新的这一漏洞。

近期发现的其他 UEFI 漏洞包括：

• PKFail，这是一起供应链失败事件，起因是用于数百种设备型号的非生产测试平台密钥，这些密钥已公开超过十年才被发觉；
• BootHole；
• Bootkit；以及
• BlackLotus。

与 CVE-2026-97631 一样，利用这类 payload 颇具吸引力，因为它能让攻击者在系统启动早期就感染机器——赶在 TPM 和其他防御机制加载之前——从而造成最大程度的破坏。鉴于 CVE-2026-97631 的普遍性，Moore 表示它很可能成为一个“永远修不完”的漏洞，在停止支持的系统里长期存在。 不过，利用这个新漏洞有一些重要的前提和限制。如前所述，攻击者必须先对本地网络有一定程度的控制。这就把攻击面基本限定在内部人员，或是那些已经潜入网络底层权限、想进一步提权的攻击者，比如国家级黑客或勒索软件团伙。目前没有证据表明 CVE-2026-97631 能作为入侵网络的初始入口。此外还有其他门槛要过。 固件安全公司 Eclypsium 的首席研究员 Jesse Michael 告诉 Ars：“要利用这个漏洞，攻击者需要猜测目标系统内的特定地址，所以不可能用一个 exploit 通吃各种设备，而必须针对每个目标机型/版本/配置单独调整，因为地址会随这些因素变化。” “与 BootHole、Black Lotus、Baton Drop 这些此前的高知名度漏洞不同，这个漏洞可以通过简单的代码修复来解决——虽然需要部署 BIOS/UEFI 更新，但不用像 bootloader 层面的 Secure Boot 绕过那样，还要处理证书吊销、pk/kek/db/dbx 密钥管理更新，以及确保操作系统和装机介质同步更新。” CVE-2026-97631 不影响家庭、小型办公用户，或其他任何仅从磁盘驱动启动设备的用户。该漏洞仅适用于从本地网络或（理论上）从互联网连接资源启动机器的组织机构。即便在这种情况下，目标固件也必须依赖 EDK2（而非其他参考实现），并且启用了 PXE 功能（该功能默认处于开启状态）。 Intel 在一封邮件中表示，目前处于安全支持范围内的其“商业产品”均未发现受到影响。“Intel 的参考代码中不包含受影响的 EDK2 功能，尽管 OEM 板卡供应商或系统制造商可能会将其集成”，该公司补充道。Intel 建议客户咨询其系统制造商以获取具体指导。然而，公开可用的 Intel 参考代码 中确实引用了 EDK2。此外，TianoCore 曾指出，每个由 Intel 提供的 UEFI 开发套件“都是针对特定版本 EDK II 源代码的完整验证实现……”。许多其他 Intel 文档也引用了 EDK2。 与此同时，Arm 针对一系列问题回应称：“CVE-2026-97631 不直接适用于 Arm 的产品组合。”与 Intel 类似，该公司公开的 固件 也大量借鉴了 EDK2。TianoCore 也曾 记录 了 Arm 对 EDK2 的依赖情况。 尽管某些平台可能不包含 EDK2 代码，但所有服务器用户都明智地应调查 CVE-2026-97631 是否对其产生影响。 向 AMD、Phoenix Technologies、AMI、Microsoft 和 Amazon——这些可能都深受影响的头部企业——发送的质询信，在本文发布时均未收到回复。若无法获取这些机构使用 EDK2 的具体情况，便无从判断哪些设备受到何种程度的影响，也无法明确这些机构或其用户应否采取行动以及如何应对。TianoCore 项目的相关代表同样未予回应。 部分读者或许会对信息缺乏细节而不满。但有时——尤其是涉及信息披露失败、禁令解除日期远早于公布时间这类情况——初期报道中难以提供可操作的细节信息实属无奈。 受影响方应联系系统固件的制造商寻求指导。此外，如果条件允许，至少应暂时关闭网络启动功能。在可行范围内，固件配置始终应启用 TPM 和安全启动（Secure Boot）等安全特性，尽管这些防御措施无法抵御当前的特定威胁。同时，监控日志中是否出现被利用的迹象也是一个明智之举。 本文最初发表于 Ars Technica。