16-year-old EDK II flaw can run code before Secure Boot on network-booting servers
A buffer overflow in the EDK II PXE driver, tracked as CVE-2026-97631 and rated 9.5, can crash or hijack servers during network boot. No stable patched release exists yet.
At a glance
- CVE-2026-97631 is a buffer overflow in EDK II's PXE network-boot driver, rated 9.5 by TianoCore.
- An attacker needs only to send a crafted error message during a network boot, with no prior access.
- Code can run before Secure Boot, mainly affecting servers and data center gear that boot over the network.
- A fix is merged upstream but no stable EDK II release includes it yet; disabling PXE is the main workaround.
A 16-year-old buffer overflow in EDK II, the open-source UEFI reference code that most firmware vendors build on, can be triggered over the network during PXE boot and may let an attacker run code before Secure Boot checks, The Hacker News reports. Tracked as CVE-2026-97631, the flaw was rated 9.5 out of 10 in TianoCore's advisory (GHSA-99cj-7hg9-mp4m) published on October 22, and no patched stable release exists yet.
Technical details
According to The Hacker News, the EDK II PXE driver copies ICMP error messages and related status messages into a fixed 504-byte buffer, but the size checks are wrong in both the IPv4 and IPv6 code, so longer messages overwrite nearby memory. The flawed copy loop dates to a commit from November 2010. An attacker needs no password or prior access — only the ability to send one crafted error message to the machine's address while it is performing a network boot. The most likely outcome is a crash or hung boot; code execution is much harder and, per the advisory, requires knowing the exact firmware build to craft what it calls a counterfeit event.
Why it matters
The Hacker News notes that any injected code runs before Secure Boot and other boot-time checks, which is what makes the flaw serious. Although injected code runs only once and does not persist on its own, it can install code that runs on every boot, and the boot stage can still reach sensitive components such as the TPM — which researchers say could help defeat disk encryption in some scenarios. Eclypsium's Jesse Michael is quoted saying that, unlike Secure Boot bypasses, the flaw can be fixed with a basic code fix and does not require certificate or key revocations. Dragos research chief HD Moore is cited warning the bug could let an attacker hijack program flow while the boot process still has access to sensitive components.
Who is affected
EDK II versions up to and including edk2-stable202608 are affected, The Hacker News reports, and EDK II is the base for AMI, Insyde, Phoenix, and Microsoft's Project Mu. Red Hat lists edk2 in RHEL 8, 9, and 10 as affected and unfixed, and SUSE and Debian mark their packages the same way. Because PXE is enabled by default in EDK II's standard build, the likely impact falls on servers and data center equipment that boot over the network; machines that boot only from local disks are not affected. Intel said none of its commercially supported products it knows of are affected, and Arm said the flaw is not directly applicable to its portfolio. The flaw was credited to Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google.
What to do
A fix (PR #13302) was merged into the EDK II main branch on October 15 and truncates oversized messages, but the advisory still lists the patched version as not available, so server operators must wait for their firmware maker to ship a BIOS or UEFI update. In the meantime, The Hacker News reports there is no sign of exploitation and the flaw was not in CISA's Known Exploited Vulnerabilities catalog as of its October 27 update. Operators who do not need PXE should disable it, and monitoring boot-time network traffic and logs is also suggested.
Related CVEs
Sources
This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.



