A single ICMP error message longer than 504 bytes is enough to write past a buffer in the UEFI firmware of a server booting over the network. The bug, CVE-2026-97631, lives in TianoCore EDK II, the open source UEFI firmware code maintained by TianoCore and forked by downstreams such as Microsoft and XCP-ng, and its official advisory rates it 9.5 out of 10 on CVSS v4. The fix has been public since October 14, 2026, yet no stable EDK II release ships it.
What exactly breaks
EDK II's PXE driver (NetworkPkg/UefiPxeBcDxe) keeps a receive open for ICMP error messages while the machine network-boots, and copies each one into a fixed 504-byte field, Mode.IcmpError. According to the security advisory published on October 22, the functions that do this for IPv4 (PxeBcIcmpErrorDpcHandle) and IPv6 (PxeBcIcmp6ErrorDpcHandle) get the bounds wrong: given a longer message they keep copying, and they advance the destination pointer by the cumulative length instead of the per-fragment length. Nothing earlier on the receive path caps the message size.
The advisory describes two outcomes:
- Deterministic denial of service: the driver's private data gets corrupted and the next ICMP error triggers a CPU exception in the DXE core that hangs the boot.
- Code execution: an attacker who knows the exact firmware build can plant a counterfeit event in the same packet so that
CoreSignalEvent()runs their bytes in the DXE phase. That is before the operating system loads, and therefore out of reach of any security agent running on it.
Who is exposed
The preconditions are specific: the machine has to be PXE-booting over IPv4 or IPv6, and the attacker has to deliver a unicast ICMP error addressed to its IP. The advisory stresses this works "from any network distance", not just from the same segment. The window lasts as long as the PXE boot, so the risk concentrates on bare metal fleets that are provisioned or reimaged over the network, and on hypervisors that give their VMs UEFI firmware with network boot. A server booting from disk never opens that window.
The advisory lists the affected version as "EDK II master as of 2026-09-14" and the patched version as "Not patched currently". What it does not say is which server vendors carry this code in their firmware; that is up to each of them.
A public patch before the advisory
The timeline is what makes this CVE urgent. The fix, PR #13302, was opened in the open on October 14 and merged into master on October 15 (commit fa78907). In the thread itself, a project maintainer admits the embargo "was violated due to a mistake", which is why the PR went up publicly. The official advisory followed a week later, on October 22, crediting Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google).
Since then anyone can read the diff to work out how to trigger the bug, while the latest stable release, edk2-stable202608, dates from August 21 and does not include it. Downstream forks are moving: Microsoft merged the backport into the release/202511 branch of mu_basecore on October 23, and XCP-ng merged it into the 8.3 branch of its edk2 package on October 28, so far only build-tested, without its test suite.
What I would do this week
- Inventory what boots over the network: servers provisioned or reimaged via PXE and UEFI VMs with network boot. That is the real attack surface, not "every server".
- Drop network boot where it is not needed: if a machine is already installed and boots from disk, removing PXE from the boot order closes the window without waiting on anyone.
- Filter ICMP errors entering the provisioning network from outside it. Since the attack can come from any distance, the edge of that segment is the natural choke point. On IPv6, take care not to break path MTU discovery for the rest of the traffic.
- Ask your vendor for firmware that references CVE-2026-97631, and if you build your own firmware from EDK II, apply commit
fa78907instead of waiting for the next stable tag.
The caveat that matters: the 9.5 assumes an attacker who can reach the machine while it network-boots and, for code execution, knows its firmware build. This is not an internet worm, but with the patch public since October 14, building the exploit is a matter of reading the diff.
Sources
- Pre-boot RCE in EDK II PXE driver (CVE-2026-97631), TianoCore EDK II
- NetworkPkg/UefiPxeBcDxe: Fix ICMP buffer overflow in IPv4/IPv6 handle (CVE-2026-97631), TianoCore EDK II
- EDK II releases (edk2-stable202608), TianoCore EDK II
- Backport CVE-2026-97631 from edk2, Microsoft mu_basecore
- Add fixes for CVE-2024-38797 and CVE-2026-97631, XCP-ng