A critical buffer overflow in the network boot code of TianoCore EDK II, the open-source UEFI firmware base, can let an attacker on the same network run code before the operating system and Secure Boot load. Tracked as CVE-2026-97631 with a CVSS score of 9.5, the flaw is 16 years old, and no stable EDK II release yet contains a fix.
How CVE-2026-97631 Overflows the PXE Driver’s ICMP Handling
The bug sits in the PXE driver’s handling of ICMP error messages. The driver copies those messages into a fixed 504-byte area, and the size checks are wrong in both the IPv4 and IPv6 code. A longer message therefore overwrites adjacent memory.
TianoCore published its advisory on October 22 and assigned the 9.5 score. A code fix exists, but no stable EDK II release includes it, and the advisory lists no patched version.
What an Attacker Can Do During the Network Boot Window
A single crafted message sent while a machine is network-booting can hang the boot. With work tailored to the exact firmware build, an attacker can plant a counterfeit event and execute code before the operating system and Secure Boot load. No password or prior access is required, but the attacker must sit on an adjacent network during the boot window. Red Hat and SUSE both rate the flaw as adjacent-network.
Crashing a machine is easy, while reliable code execution is harder. Researchers have not reported any exploitation.
Red Hat and SUSE Ship the Affected Code
The affected code appears in distributions from Red Hat and SUSE, so organizations that run those systems and PXE boot their servers are in scope. Apply-as-available distribution patches are the stated remedy, because the upstream project has not issued a stable release containing the fix.
Limiting PXE Exposure While No Patched Release Exists
With no patched version to install, the guidance is to restrict PXE booting to isolated provisioning networks. That reduces the chance that an attacker shares a network segment with a machine at the moment it boots. Servers that PXE boot are the group at risk, since they are exposed to pre-OS code execution.
Why Pre-OS Execution Defeats the Usual Defenses
The significance of a flaw in this layer is where the code runs. Anything executed before the operating system loads sits below endpoint protection, disk encryption prompts and the integrity checks that Secure Boot is meant to enforce. Code placed there can shape what the operating system sees, which is why firmware flaws are treated as a separate class of risk from application bugs.
The 16-year age of the bug also reflects how long code in the network boot path can go without close scrutiny. EDK II is a shared base used by many firmware vendors, so a flaw in it can ripple across products, though the advisory’s named distribution impact is limited to Red Hat and SUSE.
The conditions limit the practical risk. The attacker must be on the same network during a boot, tailor the attack to the firmware build and accept an unreliable result. For a data center that provisions servers on a controlled network, that is a high bar. For environments that PXE boot machines on shared or lightly segmented networks, it is lower, and the lack of a stable fix means the exposure will last until distribution patches arrive.
The lack of a patched release also complicates how organizations can track their exposure. Because the advisory lists no fixed version, vulnerability scanners that check for a specific EDK II build number have nothing to compare against, and teams depend on distribution vendors such as Red Hat and SUSE to publish their own patched packages. Until those arrive, the flaw remains open on every system that ships the affected PXE code.
