A critical vulnerability in the open-source firmware code underneath most of the world's servers and PCs can let an attacker on the local network run code before the operating system — and before Secure Boot — ever intervenes. The flaw, tracked as CVE-2026-97631 and rated 9.5 out of 10 under CVSS v4, sits in TianoCore EDK II, the reference codebase firmware makers build UEFI firmware on. TianoCore issued its advisory on October 22, months ahead of the disclosure the researchers who found the bug had planned.
The bug lives in the PXE Base Code driver, UefiPxeBcDxe, part of EDK II's NetworkPkg. That driver lets a machine pull its boot image over the network instead of from a local disk, routine in data center provisioning and enterprise imaging. While a PXE boot is under way, it listens for ICMP error messages and copies them into a fixed 504-byte field. According to the advisory, the copy loop gets its bounds wrong in both the IPv4 and IPv6 handlers: the destination pointer advances by the cumulative length rather than the per-fragment length, and nothing earlier caps the message size. A single oversized, unicast ICMP error message aimed at a booting machine can therefore write attacker-controlled bytes past the end of the buffer.
At minimum, the overflow hangs the boot. In the worse case, an attacker who knows the exact firmware build can steer it into executing supplied code during the DXE phase — ring 0, before the operating system loads and before the measurements that Secure Boot and the Trusted Platform Module are supposed to anchor. Code delivered through the flaw runs once and is not itself persistent, but it can install other payloads that execute early in every subsequent boot. Speaking to Ars Technica, Dragos chief research officer HD Moore noted that the boot process still has access to the TPM at that stage, and named breaking disk encryption as one realistic use.
The exposure is broad but conditional. Virtually all UEFI suppliers — the independent BIOS vendors AMI, Insyde and Phoenix — build extensively on the EDK II reference code, and Microsoft's hardened EDK II fork, Project Mu, carried the same vulnerable component. The flaw only triggers while a machine is network booting, however, and the attacker needs a position on a network that can reach it; machines that boot only from local disk are outside the reported exposure, and code execution must be tuned to the target's firmware build. Ars Technica reported no evidence of exploitation as of October 27. Intel told Ars none of its commercial products under security support were known to be affected, and Arm said the flaw was not directly applicable to its portfolio.
The disclosure itself went sideways. Alex Matrosov of Anthropic and Dan Holmes of Google discovered the vulnerability and had arranged a coordinated disclosure for January. That plan collapsed after AMI published a pull request last month describing the flaw and including a code fix, prompting TianoCore to publish early. With patch code now public, advanced attackers can study the fix to work out how to trigger the flaw.
An upstream EDK II fix has been merged, adding bounds checks, safe truncation and buffer clearing, but upstream code and shipped firmware run on separate clocks: system and motherboard makers must still ship updated firmware for their specific builds. Until they do, administrators should inventory which servers, workstations and provisioning systems actually use PXE boot, watch their vendors' firmware advisories, disable network boot where it is not needed, and keep PXE traffic on segmented, trusted networks with unexpected ICMP error traffic filtered out.