A critical buffer overflow in TianoCore’s EDK II firmware codebase allows an unauthenticated, remote attacker to execute code before the operating system loads, bypassing Secure Boot and measured boot protections. Tracked as CVE-2026-97631 and rated 9.5 out of 10 for severity, the flaw resides in the PXE network boot driver and affects both IPv4 and IPv6. A fix was merged into the EDK II source code on October 15, but stable firmware releases and vendor updates remain unavailable, leaving many servers exposed.
- Pre-boot remote code execution: An attacker who can deliver oversized ICMP error messages to a machine during PXE boot can corrupt DXE-phase memory and run arbitrary code before any OS-level security check.
- Limited but serious exposure: Only systems actively booting over the network with affected firmware are vulnerable; servers that boot solely from local disks do not use the flawed path.
- Patch gap: The source code fix exists, but no stable EDK II release, Debian package, or major vendor advisory has shipped a patched firmware image yet.
Anatomy of the Flaw
EDK II is the open-source development kit that firmware vendors use to build UEFI, the low-level software that initializes hardware and starts the boot process. The vulnerability lies in the PXE driver, which stores incoming network error messages in a fixed 504-byte buffer without validating their size. An oversized ICMP error message overflows that buffer and overwrites adjacent memory with attacker-controlled data.
The impact has two tiers. The simpler outcome is a hung boot that prevents the server from loading its OS or recovering. The more severe scenario, according to TianoCore’s advisory, is that an attacker who knows the target’s specific firmware build can smuggle instructions into the same packet and execute them before Secure Boot or measured boot has verified any OS component.
“While a machine is PXE-booting over IPv4 or IPv6, an unauthenticated network attacker who can deliver ICMP error messages to it can corrupt DXE-phase memory and execute arbitrary code before the operating system loads,” TianoCore said.
The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google with discovering the flaw and recommending the fix. An EDK II contributor appearing on GitHub as motherboard maker AMI, based in India, publicly detailed the vulnerability and submitted a proposed fix on September 28, two weeks before TianoCore’s official disclosure.
Who Is Actually at Risk
Exposure requires three conditions: affected firmware, a machine actively booting over the network, and network reachability during that boot window. An attacker does not need credentials but must know the target’s firmware version to achieve code execution. TianoCore says the message can arrive from any network distance, while Red Hat assigns a more limited local-network rating.
Servers that boot only from local disks never enter this attack window. The same applies to machines that do not use the affected PXE driver. This is why claims that the flaw threatens “most servers on the planet” overstate the real number of exploitable machines; at most, they describe the potential scope of the code, not the actual attack surface.
Hetzner, a major hosting provider, warned customers on October 28 that hosts using PXE boot should avoid reboots until further notice. The notice remained in “Investigating” status on October 29 with no official patch announced. For hosts already running, Hetzner said there is no direct risk from the flaw.
Debian, which distributes EDK II as a software package for virtual machines, lists vulnerable versions across its Bookworm, Trixie, Forky, and Sid releases but has not issued a fixed package. The OVMF firmware image used by virtual machines requires its own update check, separate from the guest Linux packages.
The Firmware Patching Problem
The source code fix was merged into EDK II’s main branch on October 15, and Microsoft carried it into its Project Mu firmware variant on October 22. But TianoCore’s advisory still marks the issue as “Not patched currently” in the absence of a new stable release. No major firmware vendor, including AMI, has published a security advisory for the flaw.
This is the perennial firmware dilemma: a fix must travel from the open-source project to the firmware vendor, then to the server manufacturer, and finally to the administrator who installs the BIOS update. Each link adds delay, and the chain often stretches months.
As of October 28, there was no confirmed exploitation in the wild. The practical guidance for administrators is to disable PXE boot where it is not needed and apply firmware updates as soon as vendors publish them. Secure Boot does not mitigate this flaw, because the vulnerable driver handles network data before Secure Boot verifies any OS component.
The broader lesson is that pre-boot code remains a blind spot for conventional defenses. Security tools running inside the operating system cannot inspect packets while firmware is handling them. Until firmware vendors ship patched images, the most reliable protection is reducing the attack surface by turning off network boot on servers that do not require it.