A 16-year-old bug at the heart of server UEFI firmware worldwide has been discovered and rated at maximum severity: 9.5 out of 10. The flaw, tracked as CVE-2026-97631, resides in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) of TianoCore EDK II — the open-source reference implementation that powers virtually all server UEFI firmware manufactured by AMI, Insyde, Phoenix, and other major suppliers.
What makes this flaw particularly dangerous is where it executes. The exploitation occurs during PXE boot — the network initialization process — before the operating system loads and before mechanisms like Secure Boot or measured boot have verified any component. Malicious code runs at ring 0, the CPU's most privileged execution level, with direct access to the TPM and all sensitive system components.
The vulnerability's mechanism is elegant in its simplicity. During PXE boot, the driver keeps a receive port open for ICMP error messages. The code copies each received message into a fixed 504-byte field (Mode.IcmpError) without size validation. An attacker on the same network can send ICMP messages longer than 504 bytes, corrupting DXE-phase memory and executing arbitrary code. No credentials required, no user interaction needed — simply reach the machine over the network during the boot window.
The discovery was credited to Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google. The patch was merged into EDK II master on October 15, 2026 (PR #13302), but the latest stable tag, edk2-stable202608 from August 21, does not yet include the fix. TianoCore's advisory lists the status as "Not patched currently."
The impact is broad but not universal. Most modern servers use EDK II with PXE network boot for data center provisioning. However, machines that boot exclusively from local disk — such as most personal laptops and desktops — are unaffected. This distinction matters: data centers that rely on network boot for provisioning, maintenance, or infrastructure scaling are in the line of fire.
The absence of persistence in final payloads is both a relief and a cause for concern. The exploit runs once and dies — but this initial vector opens the door to installing persistent bootkits that survive OS reinstallations. UEFI firmware lives in the physical chip on the motherboard, unreachable by conventional software tools. Once compromised, firmware can reinject any malware on the next boot, regardless of changes made to the disk.
The immediate mitigation is straightforward but impactful: disable PXE/network boot where it is not essential. For administrators who depend on this functionality for provisioning, waiting for vendor firmware patches is the only path forward. Debian has already tracked the CVE in its security tracker, but this is classification, not remediation.
The question that remains is whether EDK II's architecture — 16 years without formal security review — reflects a systemic problem in the firmware ecosystem. As computing migrates to edge, IoT, and embedded systems running UEFI, this is the same architecture that secures data centers while simultaneously exposing them. The next pre-boot vulnerability likely won't wait 16 years to appear, and the gap between discovery and patch may prove even wider in practice.
Sources: pwn.watch, GitHub Advisory — TianoCore EDK II, Debian Security Tracker
✓ Independent sources cross-checked and verified before publishing
