www.it-connect.fr
UEFI Flaw CVE-2026-97631 Lets a Single ICMP Packet Run Code Before Secure Boot
One ICMP message, sent at just the right moment, is enough to execute code on a machine before Secure Boot even checks anything. That is the attack scenario tied to a new security flaw (CVE-2026-97631), discovered in UEFI code by two researchers from Anthropic and Google. Here is what we know about this vulnerability.
On October 22, 2026, the TianoCore project published a security bulletin dedicated to a critical flaw in EDK II, the open source implementation of the UEFI specification. The name may not mean much to you, yet it is the code base used by many firmware vendors, including AMI, Insyde, and Phoenix. This flaw, tracked as CVE-2026-97631, carries a CVSS 4.0 score of 9.5 out of 10, making it a serious critical vulnerability.
A buffer overflow during PXE boot
The vulnerability discovered by Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) is located in the PXE driver (NetworkPkg/UefiPxeBcDxe). During a network boot, it copies each ICMP error message received into a fixed-size 504-byte field. The problem is that the bounds checking for this copy is incorrect, both for IPv4 and IPv6. A message that is too long can therefore overflow the field and write attacker-controlled data into adjacent memory.
The security bulletin published by TianoCore highlights two risks:
- Denial of service: corruption of the driver’s data triggers a CPU exception in the DXE core, and the boot process stalls.
- Code execution: an attacker who knows the exact firmware version targeted can slip a fake event into the same packet and make their own bytes execute during the DXE phase, with ring 0 privileges.
No authentication is required, and the code runs "before Secure Boot or measured boot has verified or measured any OS component", TianoCore says.
How can you protect yourself?
Even though this flaw was disclosed a few days ago, the fix had already been visible on GitHub well before that. On September 28, 2026, a pull request referencing the CVE was opened in the EDK II repository. Taken over by Michael D. Kinney, one of the maintainers of this open source project, it led to pull request 13302, merged into the main branch on October 15.
The good news is that the EDK II code is fixed, but the bad news is that the bulletin still lists no fixed version. The patch still has to pass through each firmware vendor, then each hardware manufacturer, before reaching your machines as a BIOS/UEFI update. On the virtualization side, with OVMF firmware for UEFI VMs, distributions are moving faster: NixOS has integrated the patch and Red Hat says it is working on a fix.
This security flaw could affect millions of machines, including servers, as long as EDK II is used by the BIOS/UEFI. That said, the exploitation window is very short: it only lasts for the duration of the PXE boot. This also means that a server booting from its local disk does not go through this driver. Be careful, however, with the boot order: if PXE comes before the disk, or is used as a fallback, the exploitation window exists at every reboot.
