A single ICMP packet during PXE boot runs code before Secure Boot checks anything
On October 22, 2026, TianoCore published an advisory on CVE-2026-97631, a buffer overflow (CVSS 4.0: 9.5) in the EDK II PXE driver that lets a forged ICMP packet execute code at ring 0 before Secure Boot verifies anything. Check your servers’ boot order and disable PXE wherever it is not essential, because no patched firmware has shipped yet.
October 22, 2026. The TianoCore project publishes a security advisory (GHSA-99cj-7hg9-mp4m) on EDK II, the open-source implementation of the UEFI specification used by the major firmware vendors — AMI, Insyde, and Phoenix. CVSS 4.0: 9.5. The flaw, CVE-2026-97631, sits in the PXE network-boot driver. One ICMP packet. That, according to researchers Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google), is enough to run code before Secure Boot has verified anything at all.
A buffer overflow in the PXE driver
The defect lives in NetworkPkg/UefiPxeBcDxe, EDK II’s PXE driver. During a network boot, this driver copies every ICMP error message it receives into a fixed 504-byte field. The bounds handling of that copy is wrong, in IPv4 as well as IPv6: an overlong message overflows the field and writes attacker-controlled data into adjacent memory. It is a classic buffer overflow, buried in the heart of the firmware’s DXE phase — the part that initializes the hardware just before handing off to the operating system.
The advisory describes two outcomes. The first is denial of service: corrupting the driver’s data triggers a CPU exception in the DXE core, and the boot hangs. The second is code execution: an attacker who knows the exact firmware version of the target can slip a forged event into the same packet and have their own bytes executed during the DXE phase, with ring 0 privileges.
The detail that changes everything: no authentication is required, and the code runs “before Secure Boot or measured boot has verified or measured any component” of the OS, TianoCore notes. Secure Boot verifies what comes after the firmware — the bootloader, the kernel, the signed drivers. Here, the compromise happens inside the firmware itself, upstream of everything Secure Boot can police.
Why network boot is the firmware blind spot
PXE boot is the neglected corner of firmware security. Teams harden Secure Boot, the TPM, measured boot, certificate revocations — and often leave PXE enabled “just in case,” for automated deployment or a disaster-recovery plan. That is exactly the surface CVE-2026-97631 turns into an entry point.
The exploitation window is short — it lasts as long as the network boot — but it repeats at every reboot whenever PXE sits ahead of the disk in the boot order, or is configured as a fallback. A server that boots from its local disk never touches this driver; a server that tries the network on every cycle replays the vulnerability at every power-on. The attacker does not need to be on the same segment at a precise instant: they need to be able to send an ICMP packet to the machine at the moment it asks the network for an address.
The scope is enormous. Because EDK II underpins most of the market’s BIOS/UEFI implementations, the flaw potentially affects millions of machines, servers included. Virtualization is not spared either: the OVMF firmware of UEFI virtual machines ships the same code.
A fix with no shipped version
The patch story illustrates the firmware supply-chain bottleneck. Pull request 13302, carrying the CVE reference, was merged into EDK II’s main branch on October 15, 2026. The upstream code is fixed. Yet the October 22 advisory still lists no patched version: the fix must still pass through each firmware vendor, then each OEM, before reaching machines as a BIOS/UEFI update.
Virtualization moves faster. NixOS has integrated the patch into its OVMF package, and Red Hat says a fix is in progress. For physical servers, the delay is measured in weeks, if not months, depending on each vendor’s responsiveness and the platform’s age — with end-of-support machines at risk of never receiving a fix at all.
# On a Linux host, inspect the boot order and the presence of PXE entries
efibootmgr -v
# Disable a PXE entry when it is not needed (entry number is indicative)
efibootmgr -b 0004 -AThe habit to break is assuming “the firmware is up to date”: here, no firmware is up to date, because none has shipped. Immediate protection comes not from the patch but from shrinking the surface — turning off network boot where it is unused, and hardening the boot order.
How the attack unfolds, step by step
The scenario runs in four stages, all before the operating system loads. First, the machine boots over PXE and broadcasts an address request; the UefiPxeBcDxe driver listens for DHCP replies and the associated ICMP messages. Next, the attacker — on the same boot VLAN, or able to inject a packet into it — answers with an overlong ICMP error message. The driver copies it into its 504-byte field without checking bounds, and the overflow smashes adjacent memory. Third, if the attacker knows the exact firmware version, they slip a forged event into the same packet that causes their bytes to run during the DXE phase, at ring 0. Fourth, that code runs before Secure Boot or measured boot has verified any component — the machine is compromised before it has even started to boot.
The point about measured boot is worth hammering: measuring a component assumes it loads after the root of measurement is established. Here, the compromise happens inside the firmware, before that root. The TPM log will hold no trace of the malicious execution, because nothing was yet in a position to measure it. That is what separates this flaw from a mere Secure Boot bypass: it sits upstream of the entire chain of trust, where no verification was ever designed to run.
The immediate mitigation is therefore network-level before it is software-level. Isolate boot traffic on a dedicated VLAN, enable DHCP snooping and source protection on the switches that see the boot, and expose PXE only to machines that actually need it. A server that never boots from the network has no business listening for those packets — and every packet it does not listen for is a closed attack surface.
Worth noting is the disclosure cadence. The flaw was reported by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google; the fix was merged upstream on October 15, the advisory followed on October 22, and here we are at month’s end with no OEM firmware in hand. That gap — a working patch sitting in a repository while vulnerable firmware still runs in datacenters — is the real story of firmware vulnerabilities. The window is not the time it takes to develop a fix; it is the time it takes to ship one through a chain of vendors, each with its own release train and support matrix.
Verdict
If your servers boot over PXE — automated deployment, disaster recovery, bare-metal as a service — treat them as exposed until patched firmware lands, and prefer UEFI HTTP Boot or local boot where possible. If PXE is not essential, disable it and put the disk ahead of the network in the boot order: it is the only mitigation actually available today. For virtual machines, apply your distribution’s OVMF updates without delay. And if you manage a fleet of physical servers, inventory every platform that boots from the network and track, OEM by OEM, the arrival of the fix — the upstream patch exists, but the chain that must carry it to your machines has not yet delivered.