EDK II flaw lets a network attacker run code while a server PXE-boots

EDK II flaw lets a network attacker run code while a server PXE-boots

22 October 2026: A critical flaw in EDK II, the open-source UEFI codebase that most PC and server firmware is built on, lets an unauthenticated attacker run code on a machine while it boots from the network. CVE-2026-97631 is rated 9.5 under CVSS 4.0, and the TianoCore advisory published on 22 October lists no patched version, only a proposed fix in pull request 13302.

Not yet independently verified. The flaw and its scoring rest on the TianoCore advisory. We have not yet seen advisories from the firmware vendors (AMI, Insyde, Phoenix) or server makers that ship EDK II code, so which products and firmware versions are affected in practice is not yet known. We will update this when it can be confirmed, and remove this note.

Where the bug sits

The problem is in the PXE Base Code driver, NetworkPkg/UefiPxeBcDxe. During a network boot the driver keeps a receive request open for ICMP error messages and copies each one into a fixed 504-byte field. The advisory says the copy loop handles bounds wrongly in both the IPv4 and the IPv6 handler: it keeps copying when a message is longer than 504 bytes, and it moves the destination pointer by the cumulative rather than the per-fragment length. An oversized message therefore writes attacker-chosen bytes past the field, and nothing earlier on the receive path limits the length.

The affected version is given as EDK II master as of 14 September 2026. The flaw was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, who also supplied the recommended fix.

What an attacker gets

The attacker needs no credentials and no position on the local network. According to the advisory, a unicast ICMP error message addressed to the booting machine's IP address, sent from any network distance, is enough, and the exposure lasts as long as the PXE boot does. Two outcomes are described:

• a deterministic crash in the DXE core on the next ICMP error, which hangs the boot and blocks provisioning or recovery;
• for an attacker who knows the exact firmware build, a counterfeit event planted in the same packet, which the firmware then dispatches as code in the DXE phase at ring 0.

The second case runs before Secure Boot or measured boot has checked or measured any part of the operating system, so the usual OS-level controls never see it.

Why the fix will be slow to arrive

EDK II is a reference implementation. Very few organisations run it directly; they run firmware from a server or PC maker, which in turn builds on code from an independent BIOS vendor. A fix merged into EDK II still has to travel through each of those layers before it reaches a machine as a BIOS update,.

What to do before firmware updates exist

The exposure only exists while a machine is PXE-booting. The practical steps the advisory's scope suggests are:

• turn off network boot in firmware settings on machines that do not need it, which covers most servers once deployed;
• keep PXE traffic on an isolated provisioning network where it is needed, so that ICMP from outside cannot reach a booting host;
• watch the firmware advisories of your server and laptop makers for CVE-2026-97631.

Our catalogue lists 7 endpoint protection products and 12 endpoint detection and response tools; none of them inspects firmware network traffic during boot, which is where this flaw lives.

Sources

• TianoCore EDK II: GHSA-99cj-7hg9-mp4m, Pre-boot RCE in EDK II PXE driver, 22 October 2026