Unpatched EDK II Flaw Lets Attackers Hit Network-Booting Servers Before Secure Boot Starts

A buffer overflow that has sat in the open-source UEFI reference code for roughly sixteen years can crash a server while it boots from the network, and, in the worst case, run attacker-supplied code before Secure Boot has even initialised. The bug is tracked as CVE-2026-97631 and carries a CVSS score of 9.5. It lives in EDK II, the TianoCore codebase that almost every firmware vendor builds on. A fix exists in the project's main development branch, but as of 28 October 2026 no stable EDK II release ships it, and most server owners have nothing to install yet.

What happened

EDK II includes the PXE network-boot stack that lets a machine fetch its startup image from the network instead of a local disk. While a PXE boot is in progress, the driver accepts ICMP error messages and small status replies from the network and copies them into a fixed 504-byte buffer. The length checks around that copy are wrong in both the IPv4 and IPv6 code paths, so a single crafted message longer than 504 bytes spills past the buffer and overwrites adjacent memory with data the attacker chose.

The faulty copy loop traces back to a commit from November 2010. Every EDK II version up to and including edk2-stable202608, the current stable tag from August 2026, carries it. PXE boot is enabled by default in the standard EDK II build, which is why so many downstream products are in scope: the independent BIOS houses AMI, Insyde and Phoenix, Microsoft's hardened fork Project Mu, and the edk2 packages shipped by Red Hat Enterprise Linux 8, 9 and 10, SUSE and Debian, which are mostly used as the UEFI firmware for virtual machines.

Disclosure did not go to plan. A coordinated release had been scheduled for January 2027, but a pull request opened on 28 September 2026 named the CVE publicly and included the patch. TianoCore then published its advisory on 22 October, with the fix already merged into the main branch since 15 October. Microsoft moved quickly and cut Project Mu builds with the fix on 26 October. On the hardware side, Intel states that none of its commercial products under security support are known to be affected and that its own reference code does not include the vulnerable functionality, although a board vendor could add it. Arm says the flaw is not directly applicable to its portfolio. AMD, AMI, Phoenix, Insyde, Microsoft and the major cloud providers have not publicly confirmed the status of their firmware, so for many fleets the honest answer today is "unknown".

Why it matters

The danger is timing. Code injected through this bug runs inside the firmware, before Secure Boot, measured boot and every operating-system control have verified anything. The attacker needs no credentials and no prior access to the machine, only the ability to reach it on the network during the short window in which it boots over PXE.

The outcomes split into two tiers. The easy one is denial of service: the boot hangs and the machine never comes up. A fleet that depends on PXE for provisioning or diskless operation can be knocked over one packet at a time. Code execution is considerably harder and far less reliable, because the payload has to be tailored to the exact firmware build. Code planted this way runs once and does not persist on its own, but one run that early in the boot chain is enough to drop something that does, or to reach secrets the boot process still holds, such as disk-encryption keys released by the TPM. In a theft or short-term-access scenario, that is a path to breaking full-disk encryption on a server or endpoint.

Two hedges are important. First, there is no evidence of exploitation in the wild: the CVE was not in CISA's Known Exploited Vulnerabilities catalogue as of its 27 October update, and nobody has reported seeing it used. Second, this is not an entry point from the internet. Red Hat and SUSE both rate the attack vector as adjacent network, and the realistic attacker is an insider or someone who already holds a foothold on a local segment and wants to dig deeper. That said, the patch is now public, and anyone capable of reading a diff can work out exactly how the overflow is triggered.

This is also not the first time the PXE stack has let EDK II down. The PixieFail set of nine flaws disclosed in January 2024 hit the same component, and the fuzzing campaigns that followed did not catch this one.

What to do

Inventory what boots over the network. Bare-metal provisioning hosts, diskless compute nodes, thin clients and virtual machines running EDK II-based firmware all qualify. If you cannot list them, you cannot protect them.
Turn PXE off where it is not needed. It is on by default in most builds. Disabling network boot in the firmware setup removes the attack surface entirely for machines that only boot from local disk.
Isolate the boot network. Keep provisioning on a dedicated VLAN, restrict which hosts can send ICMP toward booting machines, and never PXE-boot across a segment that untrusted devices can reach.
Watch boot-time traffic. Oversized ICMP error messages aimed at PXE clients, and boots that hang without explanation, are the signals to alert on until firmware is updated.
Track your vendors. There is no official workaround. The fix is a straightforward code change that needs no certificate or key revocation, unlike BootHole or BlackLotus, so OEM BIOS and UEFI updates should be simpler to roll out once they appear. Update distribution edk2 packages as soon as they are released, and prioritise hypervisor hosts where VMs PXE-boot.

A flaw like this only matters if an attacker can actually reach your booting hosts, and that is a question about your network rather than your firmware. An internal penetration test by the 4tify team answers it directly: which segments carry boot traffic, what a compromised workstation can see during a provisioning window, and whether the controls above hold up in practice.