A 16-Year-Old UEFI Bug Lets One Packet Beat Secure Boot
CVE-2026-97631, a 9.5-rated overflow in EDK II's PXE driver dating to 2010, can let someone on the local network run code before Secure Boot on network-booting machines. Firmware updates are still pending.
A buffer overflow that has sat in the open-source code behind most server UEFI firmware since 2010 can let someone on the local network run code before Secure Boot even starts, The Hacker News reports. The bug, CVE-2026-97631, is in the PXE network-boot driver of TianoCore’s EDK II, which AMI, Insyde, Phoenix and Microsoft’s Project Mu all build on. TianoCore rates it 9.5, and no stable EDK II release includes the fix yet.
For defenders
The bug: The PXE driver copies ICMP error and status messages into a fixed 504-byte buffer, and the size checks are wrong in both the IPv4 and IPv6 paths (CWE-120, CWE-131, CWE-787). An attacker on the same network who sends one crafted reply while a machine is network-booting can overflow it. No login is needed, but the attacker must already be on the local network, so this isn’t a way in from the internet. Crashing the boot is easy; reliable code execution is harder and depends on knowing the exact firmware build, according to the report. Code that runs there executes before Secure Boot checks and could be used to plant persistent firmware implants, T1542.001 (Pre-OS Boot: System Firmware), and Dragos’s HD Moore noted it could expose TPM-held secrets such as disk encryption keys.
Status: No exploitation has been seen and it isn’t in CISA’s KEV catalog. Our CVE data shows two GitHub repositories reported as proof-of-concept code. The fix was merged into EDK II’s main branch on Oct. 15 and Project Mu tagged fixed builds on Oct. 26; see the TianoCore advisory. Firmware makers still have to ship BIOS/UEFI updates. Red Hat (RHEL 8, 9, 10), SUSE and Debian list their edk2 packages, used for virtual machine firmware, as affected. Intel says none of its supported products are known to be affected and Arm says it doesn’t directly apply; THN got no answer from AMD, AMI, Phoenix, Microsoft or Amazon.
Credit and timing: Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) found it. Disclosure was planned for January 2027, but a public EDK II pull request described the flaw on Sept. 28. It sits in the same code that produced PixieFail in 2024.
What it means for you
UEFI firmware is the code that starts a computer before Windows or Linux loads. This bug matters mainly to companies whose servers boot over the network (called PXE booting), and the attacker has to be on that network already. Home PCs and laptops that boot from their own drive aren’t the target. If a provider runs your servers, this one is on them.
Do this now
- Turn off PXE network boot on any server or PC that doesn’t need it.
- Watch your server and motherboard makers’ support pages for UEFI updates that fix CVE-2026-97631, and install them.
- Update edk2/OVMF packages on Linux virtualization hosts when your distribution ships the fix.
- Keep network-boot traffic on a separate, tightly controlled network segment.
CVE at a glance
- CVSS
- 9.5 Critical (v4.0)
- EPSS
- 0.6% chance of exploitation in the next 30 days (higher than 50.3% of CVEs)
- Exploited in the wild
- Not on CISA’s KEV list
- Public exploit
- Yes, reported in 2 GitHub repositories
Data from NVD, FIRST EPSS and CISA KEV, refreshed automatically. We report whether public exploit code exists but never link to it: fake proof-of-concepts that infect researchers are common.