潜伏16年的UEFI漏洞：开机那几秒，你的所有防线都还没上线

CVE-2026-97631，CVSS 9.5，在 Secure Boot 加载之前就能执行代码，攻击窗口只有开机那几秒。 做等保测评的朋友应该都遇到过这个场景：客户问”我们上了Secure Boot，还上了 TPM ，硬盘也加密了，服务器被偷了数据也读不出来吧”。 上周之前，这个回答是可以给的。 10月22日，TianoCore发了安全公告GHSA-99cj-7hg9-mp4m。CVE-2026-97631，CVSS 4.0评分9.5。漏洞在EDK II的PXE网络启动驱动里，位置是NetworkPkg/UefiPxeBcDxe。攻击者可以在操作系统加载之前、在Secure Boot和 度量启动 做完校验之前，让代码在ring 0跑起来。 这段代码的年龄，按提交记录往前追，大概16年。 一、504字节的缓冲区，和一个算错的指针 漏洞本身不复杂，复杂的是它藏在哪。 PXE网络启动的时候，UefiPxeBcDxe驱动会挂一个接收请求，专门等着收ICMP差错报文——就是路由器告诉你”这个包送不到”的那类消息。每收到一个报文，驱动就把它拷进自己私有上下文结构里的Mode.IcmpError字段，这个字段固定504字节。 问题出在拷贝循环的边界处理上。IPv4的PxeBcIcmpErrorDpcHandle和IPv6的PxeBcIcmp6ErrorDpcHandle两个handler都写错了。报文长度超过504字节的时候，循环还在往里拷；而且目标指针是按累计长度推进的，不是按每个分片的长度推进。结果是超长报文把攻击者控制的数据写到了字段之外的相邻内存里。 接收路径上，前面没有任何地方限制报文长度。 官方公告的原话是”the copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers”，两个handler都中招，等于IPv4和IPv6双通道都能触发。 利用方式听起来很简单：从任意网络位置发一个单播报文到目标设备的IP地址，只要发在PXE启动序列的那个窗口里。不需要密码，不需要已有的访问权限，只要求一件事——目标得正在用PXE网络启动。 二、为什么这个洞比一般的RCE更麻烦 一般的内存破坏漏洞，你在操作系统里打补丁，重启，完事。 这个洞的代码跑在操作系统之前。 攻击者能做到两件事。轻的一件是拒绝服务：让启动过程卡死在那个阶段。听起来不严重，但对无人值守的机房来说，一台机器卡在PXE阶段反复重启，运维半夜得跑一趟。 重的一件才是真正的问题。如果攻击者知道目标固件的具体build，他可以在 UEFI 固件环境里”种一个伪造事件”，让恶意代码在CPU的ring 0执行。ring 0是最高的特权级，比操作系统内核还靠下。 在这个位置上，攻击者能碰到TPM。 Metasploit的作者、现在在Dragos做首席研究官的HD Moore说得挺直白：攻击者可以用这个bug在一个”启动过程仍然能访问TPM这类敏感组件”的时间点上劫持程序流，”在攻击者拥有短期网络访问权限的情况下，这可能被用来破解磁盘加密（在设备被盗场景里就更简单了）”。 这句话的分量在于：全盘加密的信任根在TPM，TPM的信任根在启动链，启动链的第一环就是固件。固件被拿下了，底下所有东西的保证都变成了假设。 更麻烦的是attestation。远程证明机制的作用是向服务器证明”这台硬件是干净的”，验的就是启动链的度量值。这条链在上游就被污染了，证明依然能通过。 固件安全厂商Eclypsium的首席研究员Jesse Michael补充了一个技术细节：利用这个漏洞需要猜目标系统里的具体地址，所以不是”一个exploit到处扔”，得针对每个目标型号、版本、配置单独调。 这个限制听起来降低了风险，但反过来看，它把攻击者筛成了有耐心的那一类。国家级行为体、勒索团伙、或者已经拿到内网低权限正在找提权路径的人，这三类都不缺耐心。 三、漏洞是怎么漏出来的：又一次提前泄密 这部分单说，因为它解释了为什么现在这么被动。 发现漏洞的是两个人：Anthropic的Alex Matrosov和Google的Dan Holmes。他们本来安排的是2027年1月做协调披露。 上个月，主板厂商AMI往edk2仓库提了一个pull request（ #13200 ），里面详细描述了漏洞，还附了修复代码。这个PR是公开的。 发现者看到之后，TianoCore项目成员上周就发了公告。 于是披露时间从明年1月，提前到了10月22日。修复代码已经在GitHub上公开，任何有能力的攻击者都能读到触发条件，反推出可用的利用。 这和六天前PHP2Shell的情况几乎是同一个剧本。那次的细节是10月20日在Hacker News泄露，PHP官方被迫把发布计划提前一天。 Ars Technica在报道里用了一个词——”another botched disclosure”，又一次搞砸的披露。两次事件相隔六天，两次都是补丁代码先走漏，两次都是防守方被迫在还没准备好的时候应对。 这里有个结构性问题：开源项目的修复走PR流程，PR是公开的。厂商内部的安全团队和开源社区之间的披露协调，中间缺少一个”补丁先合、公告后发”的机制。这次AMI提PR可能只是为了推进修复，但它客观上把整个生态的披露时间表打乱了。 四、影响面：几乎所有服务器都沾边 EDK II是什么地位？UEFI论坛去年在一份材料里直接称它为”UEFI规范的卓越解决方案/实现”。 几乎所有的UEFI供应商——业内有时叫IBV，独立BIOS厂商——包括AMI、Insyde、Phoenix，都大量使用这份参考代码。微软的Project Mu，那个号称加固过的EDK2分支，也用了包含这个漏洞组件的代码。 受影响版本是edk2-stable202608及更早，且没有打上patch #13302的 。 Red Hat的安全公告显示RHEL 8、9、10里的edk2包都被列为受影响。TianoCore在10月15日已经把修复合并到上游主分支，但到目前还没进稳定版本。 这里要区分两件事。 Intel的回应是：目前”在安全支持期内的商业产品”没有已知受影响的。理由是Intel的参考代码里不包含这块受影响的EDK2功能。但它也补了一句，”OEM板卡厂商或系统集成商可能会集成”。而且公开的Intel参考代码（FSP）里是有EDK2引用的。TianoCore自己也说过，Intel提供的每个UEFI开发套件”都是针对特定EDK II源码修订的完整验证实现”。 Arm的回应更简短：”CVE-2026-97631不直接适用于Arm的产品组合。”但Arm公开的SystemReady固件同样大量借用EDK2，TianoCore的文档里也记录了Arm对EDK2的依赖。 AMD、Phoenix、AMI、微软、亚马逊——报道发出时都没回复。 这个局面落到运维头上就一句话：得自己去问服务器厂商。 五、谁真的受影响，谁可以先放一放 这一点必须说清楚，不然又是一轮无差别恐慌。 只从本地硬盘或SSD启动的设备，不受影响。家庭和小办公室用户，也不受影响。 真正受影响的是从本地网络启动的服务器和存储设备，理论上