开源 UEFI 固件底座 TianoCore EDK II 曝出潜伏 16 年的高危代码执行漏洞 CVE-2026-97631（CVSS 4.0 评分 9.5，向量为 AV:N/AC:L/AT:P/PR:N/UI:N）。原本由发现者与社区约定保密至明年 1 月的协同修复计划，因为硬件与固件厂商 AMI 上月在 GitHub 上公开提交了一份包含漏洞细节的拉取请求（PR #13200），演变成一场跨越 24 天的源码级泄密。这是继 6 天前 PHP 严重漏洞披露搞砸后的又一起安全事故。对全球数据中心而言，最棘手的并非漏洞本身的账面威力，而是开源上游早在 10 月中旬就已修补完毕，下游各大 BIOS 供应商与服务器厂商却至今拿不出一份可用固件更新。
一场跨越 24 天的 GitHub 源码级泄密
这起事故由 Anthropic 的 Alex Matrosov 与 Google 的 Dan Holmes（官方致谢记录为 Dan Holmes-Mitra）共同发现，影响截至 2026 年 9 月 14 日的 EDK II master 分支及截至 edk2-stable202608 的稳定版。由于固件更新涉及极长的硬件供应链，发现者原本安排了保密期，计划在明年 1 月进行协调披露，留给厂商充足的打包测试时间。
真正的泄密比外界感知的更早。早在 2026 年 9 月 24 日 CVE 编号预留后仅四天，AMI 的开发人员就在 9 月 28 日向 GitHub 公开提交了 PR #13200，把 ICMP 缓冲区溢出的成因和修复代码全盘托出。更反常的是，10 月 7 日开源维护者还在该公开页面要求补充演示失败条件的测试代码；直到 10 月 14 日，社区才开启替代方案 PR #13302 并关闭原请求，次日（10 月 15 日）将修复代码（合并提交号 fa78907）合入 EDK II 主分支。
等到 TianoCore 项目组于 10 月 22 日 16:32:27 UTC 被迫发布公开安全公告（GHSA-99cj-7hg9-mp4m）时，漏洞细节与验证逻辑已经在公开仓库里躺了整整 24 天。甚至到 10 月 27 日，TianoCore 官方公告页面仍滞后地显示着当前未修补（Not patched currently），与早已合入主分支的代码状态自相矛盾。
这种开源上游透明提交与下游硬件慢速交付的错位，直接把全球数据中心推入了零日补丁空窗期。TianoCore EDK II 是 UEFI 论坛公认的开源标准实现，AMI、Insyde、Phoenix 等独立 BIOS 供应商（IBV）以及微软的硬化分支 Project Mu 均广泛引用其代码。补丁从 EDK II 主分支流向下游商业代码库，再经由服务器厂商按主板型号定制测试，最后交付给云机房刷新，往往耗时数月。
截至 10 月 27 日，在 AMI、Insyde、Phoenix 以及微软 Project Mu 的公开安全公告索引中，均未查到针对 CVE-2026-97631 的特定公告、受影响服务器列表或已修复的固件版本。面对询问，Intel 和 Arm 均表态该漏洞不直接适用于自家当前受支持的商业产品，但双方的公开参考代码与开发文档均大量引用了 EDK II；AMD、AMI、Phoenix、微软与亚马逊则干脆未予置评。
剥离恐慌滤镜后的真实触发门槛
尽管外媒给出了威胁地球上大多数服务器的惊悚标题，但拆解技术机制就会发现，普通家用电脑、办公终端以及仅从本地硬盘启动的服务器完全不受影响。
该漏洞位于 EDK II 的 PXE 网络引导驱动（NetworkPkg/UefiPxeBcDxe）中。当服务器或存储设备通过局域网下载代码启动时，驱动会开启监听以接收 ICMP 错误消息，并将其复制到私用上下文结构中一个固定为 504 字节的字段（Mode.IcmpError）。由于 IPv4 和 IPv6 处理程序（PxeBcIcmpErrorDpcHandle 与 PxeBcIcmp6ErrorDpcHandle）写错了边界检查逻辑，当收到超过 504 字节的分片消息时，程序不仅继续复制，还会按累计长度而非单次分片长度推进目标指针，导致攻击者可控的字节直接越界覆盖相邻内存。此前针对 PixieFail（同为 EDK II 的 PXE 引导漏洞）开展的多轮开源模糊测试，均漏掉了这处潜伏 16 年的隐患。
一旦在启动早期触发溢出，恶意代码就能在 CPU 最高特权的 Ring 0 级别运行，赶在操作系统、Secure Boot（安全启动）以及可信平台模块（TPM）加载前劫持系统。尽管单次载荷没有持久性，但足以作为跳板植入类似 LogoFail、PKFail 或 BlackLotus 那样在开机最初阶段驻留的底层木马。
真正裸奔的不是全网服务器，而是开启了 PXE 的机房装机内网。
但这并不意味着黑客能隔着公网随意接管运行中的云服务器。比对 TianoCore 官方公告与固件安全机构 Eclypsium 研究员 Jesse Michael 的分析，攻击者想要真正拿下机器，必须同时跨过三道硬门槛。
第一道门槛是严苛的时机与网络位置。目标设备必须集成了 NetworkPkg 并在启动时默认开启、且正处于主动进行 IPv4 或 IPv6 PXE 网络引导的短暂窗口期。尽管单播包理论上可跨越路由，但前提是攻击者已经混入局域网或装机网络（如内鬼或已攻陷内网边缘的勒索软件团伙），能够将特制数据包路由送达正在请求网络引导的客户端 IP。它并不是一个能从公网直接打穿内网边界的初始突破口。
第二道门槛是极高的代码执行调优成本。引发启动挂起（拒绝服务 DoS）很容易，但要想植入伪造事件并稳定实现远程代码执行，攻击者必须事先精确掌握目标主板的具体固件构建版本（firmware build）和内存地址布局。不同服务器型号、不同 BIOS 版本甚至不同配置下的内存地址千差万别，无法靠一套通用攻击脚本通杀。
第三道门槛则关乎磁盘加密的真实防线。Metasploit 创始人、Dragos 首席研究官 HD Moore 推测，攻击者可借此在设备被盗或短时接触网络时访问 TPM 并破解磁盘加密。但结合官方漏洞材料与微软技术文档来看，漏洞虽发生在早于操作系统验证的 DXE 阶段，官方却并未证实存在通用的磁盘加密绕过方案。在配置得当的系统上，BitLocker 默认绑定到 TPM 的 PCR 7 和 PCR 11 来决定密钥释放，一旦启用 TPM+PIN 保护机制，密钥可用性更会被推迟到身份验证之后，单靠 PXE 溢出并不能轻易撬开加密硬盘。
零补丁空窗期的机房自救指南
唯一值得庆幸的技术细节是，这次修复起来比 BootHole 或 BlackLotus 简单得多。过去那些针对引导加载程序的漏洞，往往逼着运维人员去更新繁琐的 PK/KEK/db/dbx 密钥数据库并吊销旧证书；而 CVE-2026-97631 只需要刷新一次基础的 BIOS/UEFI 固件代码即可根除。
但在各大 OEM 服务器厂商把包含提交号 fa78907 的新 BIOS 放出来之前，依赖 PXE 进行裸金属服务器自动化部署（Provisioning）和故障恢复的云服务商与大型企业机房，正处在实打实的暴露期。由于大量老旧设备已过支持期，这大概率又会变成一个长期遗留的永久性漏洞（forever day）。
- 风险.在服务器厂商提供 BIOS 补丁前的数月空窗期内，任何未隔离的自动化装机网络与默认开启 PXE 引导的裸金属机房，都可能被已潜入内网的攻击者利用单播包打瘫启动流程或植入底层驻留木马。
面对上游已公开源码、下游却集体失声的断层局面，数据中心运维团队眼下不能干等厂商公告，必须立刻采取三项防御动作：排查并关闭所有非必要的 IPv4 与 IPv6 网络启动（PXE）功能，将其改为仅从本地磁盘引导；对必须保留 PXE 自动装机的裸金属配置网络实施严格的 VLAN 隔离与流量监控，拦截异常超长 ICMP 错误报文；同时跳过模糊的公关口径，直接向主板与服务器供应商索取集成了 EDK II PR #13302 的固件更新排期表。