A flaw in the EDK II network-boot driver can give an unauthenticated attacker a route to code execution before the operating system loads. The bug affects the driver’s handling of ICMP error messages during PXE boot over IPv4 or IPv6, when firmware is still in control of the machine.
TianoCore’s security advisory says an attacker who can send an ICMP error message to a machine during that boot window can corrupt memory in the firmware’s DXE phase. In the more severe scenario, an attacker who knows the target firmware build can use the overflow to have attacker-supplied bytes dispatched as code. That happens before Secure Boot or measured boot has verified or measured any operating-system component.
How the PXE driver is exposed
The vulnerable component is EDK II’s PXE Base Code driver, NetworkPkg/UefiPxeBcDxe. While a machine is booting from the network, the driver accepts ICMP error messages and copies their contents into a fixed 504-byte field in its private data.
The IPv4 and IPv6 handlers both mishandle the copy boundaries. For messages longer than the field, the code can keep writing beyond it; the destination pointer advances using the cumulative length rather than the length of each fragment. The advisory says nothing earlier in the receive path limits the message size.
The result can be a boot hang, blocking operating-system provisioning or recovery. A more deliberate attack can corrupt the driver’s data and, if the attacker knows the firmware build, trigger code execution in the DXE phase. TianoCore describes the attack as unauthenticated and network-based, requiring a unicast ICMP error addressed to the client while it is PXE-booting. Hardware Busters characterizes the practical exposure as requiring access to the local network.
Fix is in review; firmware updates are the next step
The fix adds bounds checks and corrects offset calculations in both handlers, truncating oversized messages rather than copying past the buffer. TianoCore’s advisory identifies patch #13302 as the patch. A separate pull request, #13200, proposed a fix for CVE-2026-97631; its discussion says it was closed as a duplicate after a pull request with suggested changes was opened.
Reviewers on #13200 requested ICMP unit tests and suggested changes to the implementation. The discussion records that unit tests were added on a suggested branch to check the conditions the fix addresses. Hardware Busters reported on October 28 that the advisory still listed EDK II master as of September 14 as affected and showed no patched release.
EDK II is firmware reference code used by firmware vendors, so addressing the issue in the upstream project does not itself update every machine that includes the component. Hardware Busters says downstream OEM firmware trees will need rebuilding and validation before vendors can distribute updates. The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google with finding the issue and providing the recommended fix.
For systems that do not use network boot, Hardware Busters recommends disabling PXE and the UEFI network stack in firmware setup. Organisations that depend on PXE can keep boot traffic on an isolated network segment and watch their system or board vendor for firmware updates mentioning CVE-2026-97631. Hardware Busters also reported that no exploitation had been reported at the time of its coverage.
The immediate next step for affected system owners is to check whether their firmware vendor has issued an update for CVE-2026-97631; TianoCore’s advisory identifies the upstream patch, but downstream firmware updates remain necessary.
Sources: GitHub, GitHub, Hardware Busters
