EDK II PXE 驱动 RCE，先于 Secure Boot 执行（CVE-2026-97631）

TL;DR

• 当机器通过 IPv4 或 IPv6 进行 PXE 网络启动时，未经身份验证的网络攻击者可以发送一个超大的 ICMP 错误消息，破坏 UEFI 启动环境中的内存。这种破坏会在操作系统加载之前执行攻击者选定的字节。TianoCore 于 2026 年 10 月 22 日发布了通告 GHSA-99cj-7hg9-mp4m。
• 暴露面是任何进行网络启动的 EDK II 固件，前提是攻击者在启动窗口内能访问其 PXE 监听器。影响发生在 Secure Boot 或度量启动验证或度量任何操作系统组件之前，因此这些防御不起作用。
• TianoCore CVE 记录将其评为严重，CVSS v4.0 9.5。CISA 的 ADP 于 2026 年 10 月 30 日将利用状态记录为无，11 月 1 日核实的 KEV 数据中也没有此 CVE。所引来源未提供公开概念验证；这些情况不能排除未披露的利用。
• 通告未列出修复版本。请将 PXE 和置备网络与不可信流量隔离，禁用不必要的网络启动，并向服务器供应商确认其固件是否包含修复。

我受影响吗？

以下条件全部成立时，您处于暴露状态：

• 机器固件包含存在漏洞的 EDK II PXE Base Code 驱动或其派生版本。
• PXE 网络启动已启用，且机器通过 IPv4 或 IPv6 从网络启动或尝试启动。
• 攻击者能在该启动窗口期间向机器的 IP 地址发送单播 ICMP 错误消息，网络距离不限。

仅从本地磁盘启动的机器不受影响。漏洞位于网络启动路径本身。

上述 Debian 软件包仍存在漏洞；供应商固件须逐一确认。请识别固件，再检查是否进行网络启动：

# Firmware vendor and version string, to ask the vendor about EDK II content
dmidecode -s bios-vendor
dmidecode -s bios-version

PXE 启动在固件中配置，请逐台服务器或通过置备工具盘点。向系统制造商确认已安装固件是否包含存在漏洞的驱动及其修复。

如何修复？

通告未列出修复版本。在供应商确认修复固件之前，请降低暴露风险：

1. 将 PXE 和置备 VLAN 与不可信网络隔离，以限制网络启动期间恶意 ICMP 消息的投递。
2. 在每台不需要网络启动的机器上禁用 PXE 和网络启动，从而彻底移除存在漏洞的监听器。
3. 向服务器供应商询问其固件计划，并在更新发布时应用。根据 Ars Technica 引用的 Eclypsium 评估，该修复只需基本的代码改动和一次固件更新，无需密钥吊销或证书管理。

局限很明显。隔离只能减少谁能接触到正在启动的机器；它不修复驱动。禁用网络启动只在从不使用它的机器上消除暴露。在修复后的固件映像运行之前，网络层以下没有任何东西能阻止这次溢出本身。

根本原因是什么？

PXE 驱动把收到的每个 ICMP 错误消息复制进一个固定大小的字段，而且边界检查失效。随后这个循环把目标指针推进到该字段之外。

网络启动期间，NetworkPkg/UefiPxeBcDxe 中的 PXE Base Code 驱动为 ICMP 错误消息保持一个打开的接收请求。它把每个消息复制进其模式结构中的固定字段 EFI_PXE_BASE_CODE_ICMP_ERROR，即 Mode.IcmpError：一个 8 字节的 ICMP 头部联合体，后跟一个 494 字节的数据数组。

该字段在 MdePkg/Include/Protocol/PxeBaseCode.h 中定义：

typedef struct {
  UINT8     Type;
  UINT8     Code;
  UINT16    Checksum;
  union {
    UINT32    reserved;
    UINT32    Mtu;
    UINT32    Pointer;
    struct {
      UINT16    Identifier;
      UINT16    Sequence;
    } Echo;
  } u;
  UINT8    Data[494];
} EFI_PXE_BASE_CODE_ICMP_ERROR;

修复之前，PxeBcSupport.c 中的复制循环在 IPv4 和 IPv6 处理器中都像这样处理接收消息的分片：

  CopiedLen = 0;
  IcmpError = (UINT8 *)&Mode->IcmpError;

  for (Index = 0; Index < RxData->FragmentCount; Index++) {
    CopiedLen += RxData->FragmentTable[Index].FragmentLength;
    if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        RxData->FragmentTable[Index].FragmentLength
        );
    } else {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        CopiedLen - sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)
        );
    }

    IcmpError += CopiedLen;
  }

两个缺陷使边界检查失效。累计长度超过字段后，else 分支复制的是超出长度，而非剩余容量。根据分片布局，该写入可能超出目标字段。

这个循环还以 CopiedLen（累计总和）而不是当前分片的长度推进 IcmpError，因此写入游标随每个分片越走越远。接收路径上没有任何环节限制消息长度。因此，单个超大的 ICMP 错误消息就能把攻击者控制的字节写过 Mode.IcmpError，进入驱动的相邻数据。

如何被利用？

根据通告，攻击是启动窗口期间的一个单播数据包：

1. 机器进入 IPv4 或 IPv6 的 PXE 启动，驱动对 ICMP 错误消息的接收请求生效。
2. 攻击者向机器的 IP 地址发送一个单播 ICMP 错误消息，比 IcmpError 字段更大并携带选定的字节。只要数据包能到达正在启动的客户端，任何网络距离都可以。
3. 接收路径把该消息交给 IPv4 的 PxeBcIcmpErrorDpcHandle 或 IPv6 的 PxeBcIcmp6ErrorDpcHandle，复制循环把数据写过字段，进入相邻内存。
4. 被破坏的状态产生两种结果之一：确定性的启动挂起，或者（对于了解目标固件构建的攻击者）执行攻击者提供的字节，如下所述。

CISA 的 ADP 于 2026 年 10 月 30 日将利用状态记录为无，11 月 1 日核实的 KEV 数据中也没有此 CVE。所引来源未提供公开概念验证；这些情况不能排除未披露的利用。

攻击是如何流动的？

网络启动期间投递的一个超大 ICMP 错误，就足以破坏操作系统之前的环境。

攻击者能做什么？

通告描述了两种结果，都无需身份验证且发生在操作系统之前：

• 确定性的启动挂起。驱动私有数据的破坏会在下一个 ICMP 错误时在 DXE 核心内引发 CPU 异常，于是机器无法从网络启动。这使操作系统置备和恢复无法进行。
• 启动环境中的任意代码执行。了解目标固件构建的攻击者可以在同一数据包中放置一个伪造事件，让 CoreSignalEvent() 在 DXE 阶段分发攻击者提供的字节。代码在 ring 0 中运行，此时任何操作系统安全控制都不存在，而且早于 Secure Boot 或度量启动验证或度量任何操作系统组件。

通告要求在 PXE 启动窗口内投递 ICMP 错误，并未将攻击者限定在本地网络。实际可达性取决于路由、防火墙和置备网络的隔离。

为什么修复有效？

修复提交 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec 用按分片的边界重写了两个复制循环。IPv4 处理器现在如下：

  for (Index = 0, IcmpError = (UINT8 *)&Mode->IcmpError, CopiedLen = 0;
       (Index < RxData->FragmentCount) &&
       (CopiedLen < sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR));
       Index++, IcmpError += FragmentLen, CopiedLen += FragmentLen)
  {
    FragmentLen = MIN (
                    RxData->FragmentTable[Index].FragmentLength,
                    (UINT32)(sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR) - CopiedLen)
                    );
    CopyMem (IcmpError, RxData->FragmentTable[Index].FragmentBuffer, FragmentLen);
  }

每次迭代最多复制字段中剩余的空间。它按同一分片长度推进游标，并在字段填满时停止，因此任何写入都无法越过 Mode.IcmpError 的末端。

IPv6 处理器得到了相同的改动，合并的拉取请求为两条路径添加了分片复制测试，还添加了一个在复制前清空 ICMP 错误缓冲区的提交。对于通告点名的 ICMP 接收路径，该修复是完整的。

修复于 2026 年 10 月 15 日合入 EDK II master。截至 11 月 1 日，最新标签仍为 edk2-stable202608，Debian 将上述软件包列为未修复。这些来源无法确定所有供应商固件的状态，请向供应商确认。

如何检查我是否已被入侵？

通告未公布入侵指标。由于存在漏洞的处理器在操作系统之前运行，仅凭操作系统日志无法排除利用。失败的尝试可能不会在主机上留下有用记录。

拒绝服务路径的可观测信号在置备服务器的日志中，而不是正在启动的机器里：

# PXE boot requests seen by a dnsmasq or dhcpd provisioning server
grep -h "PXEClient" /var/log/syslog | tail -20

将置备网络上无法解释的启动挂起视为线索，而非证据：正常的网络问题也会造成相同症状。如果您的威胁模型包含置备网络上的长期攻击者，请轮换这些启动映像携带的密钥。在供应商交付修复固件后，带外验证映像完整性。

时间线

• 2026-09-24：TianoCore 预留 CVE-2026-97631。
• 2026-09-28：AMI 在 EDK II 上公开一个点名该 CVE 并包含修复的拉取请求，据 Ars Technica，这破坏了发现者原定一月的披露计划。
• 2026-10-15：重新制作的修复，拉取请求 13302，合入 EDK II master 分支。
• 2026-10-22：TianoCore 发布通告 GHSA-99cj-7hg9-mp4m 和 CVE 记录。
• 2026-10-27：Ars Technica 发布对该漏洞及披露的分析。
• 2026-10-28：通告到达 oss-security 邮件列表。
• 2026-10-30：CISA 的 ADP 记录无已知利用。 该 embargo 在通告发布前 24 天被打破：AMI 的公开拉取请求出现在 9 月 28 日，TianoCore 于 10 月 22 日发布。

常见问题

这会影响只从本地磁盘启动的机器吗？

不会。漏洞位于 PXE 驱动的网络启动路径中，从不尝试 PXE 启动的机器不会打开该接收窗口。请确认实际启动行为和固件设置，不要假定网络启动已禁用。

为什么 Secure Boot 挡不住它？

被破坏的状态和被分发的字节在 DXE 阶段运行，早于操作系统加载。Secure Boot 和度量启动在该时刻尚未验证或度量任何操作系统组件。启动后期才介入的固件安全功能根本看不到攻击者的代码。

有可安装的固件更新吗？

通告未列出修复版本。修复已于 2026 年 10 月 15 日合入 EDK II master，但截至 11 月 1 日，最新上游标签和上述 Debian 软件包尚未包含它。请确认供应商固件是否包含修复，并在更新可用时应用。

攻击者利用它需要什么？

到正在启动机器的网络可达性、一个比字段更大的单播 ICMP 错误消息，以及对目标固件构建的了解。利用需要目标特定的地址，因此每个型号、版本和配置都需要单独调优，Eclypsium 如是说。

该漏洞在现实中被利用了吗？

CISA 的 ADP 于 2026 年 10 月 30 日将利用状态记录为无，11 月 1 日核实的 KEV 数据中也没有此 CVE。所引来源未提供公开概念验证；这些情况不能排除未披露的利用。

为什么披露发生在现在？

发现者，Anthropic 的 Alex Matrosov 和 Google 的 Dan Holmes-Mitra，原定在一月进行协调披露。AMI 在 2026 年 9 月 28 日公开了一个带修复和 CVE 编号的拉取请求。此事被发现者知晓后，据 Ars Technica，TianoCore 发布了通告。

参考文献

• 通告 GHSA-99cj-7hg9-mp4m，TianoCore，CVSS v4.0 9.5： https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m （2026 年 10 月 22 日发布，2026 年 11 月 1 日核实）
• CVE-2026-97631 记录，TianoCore CNA： https://www.cve.org/CVERecord?id=CVE-2026-97631 （2026 年 11 月 1 日核实）
• EDK II 修复提交 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec： https://github.com/tianocore/edk2/commit/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec （2026 年 11 月 1 日核实）
• 已合并的修复拉取请求 13302： https://github.com/tianocore/edk2/pull/13302 （2026 年 10 月 15 日合并，2026 年 11 月 1 日核实）
• AMI 打破 embargo 的拉取请求 13200： https://github.com/tianocore/edk2/pull/13200 （2026 年 9 月 28 日开启，2026 年 11 月 1 日核实）
• Ars Technica 对该漏洞与披露的分析： https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ （2026 年 10 月 27 日发布，2026 年 11 月 1 日核实）
• oss-security 公告： https://www.openwall.com/lists/oss-security/2026/10/28/4 （2026 年 10 月 28 日发布，2026 年 11 月 1 日核实）
• CVE-2026-97631 的 Debian 追踪页面，edk2 软件包漏洞且未修复： https://security-tracker.debian.org/tracker/CVE-2026-97631 （2026 年 11 月 1 日核实）
• 修复提交时 MdePkg 中的 EFI_PXE_BASE_CODE_ICMP_ERROR 定义： https://github.com/tianocore/edk2/blob/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec/MdePkg/Include/Protocol/PxeBaseCode.h （2026 年 11 月 1 日核实）
• CISA KEV 目录，针对 CVE-2026-97631 核实的订阅源： https://www.cisa.gov/known-exploited-vulnerabilities-catalog （2026 年 11 月 1 日核实）
• EDK II 发布版本: https://github.com/tianocore/edk2/releases