Defenders worldwide are once again grappling with a critical code-execution vulnerability, this time residing in the foundational boot-time firmware used by the vast majority of server vendors and data centers. Rated 9.5 out of 10 for severity, the flaw impacts the **TianoCore EDK II**, an open-source codebase that forms the backbone of UEFI firmware. Hardware manufacturers and cloud providers, including major players like **AMI**, **Insyde**, and **Phoenix**, extensively leverage **EDK II** to create the firmware that initiates a system's boot sequence. Even **Microsoft**'s hardened **Project Mu** fork of **EDK II** utilized the vulnerable component. ### The Vulnerability: CVE-2026-97631 **CVE-2026-97631** is a memory-corruption flaw within an **ICMP** component. Attackers can exploit this to execute malicious code with the highest privileges (**ring 0**) *before* the operating system or crucial firmware defenses such as **Secure Boot**—which establishes a chain of trust for loaded code, including the **Trusted Platform Module (TPM)**—can activate. While the immediate payload lacks persistence, it provides a critical window for attackers to install other payloads that also execute early in the boot process. ### The Cat Has Left the Bag The coordinated disclosure for **CVE-2026-97631**, planned for January by discoverers Alex Matrosov of **Anthropic** and Dan Holmes of **Google**, was prematurely compromised. **AMI** inadvertently published a pull request last month detailing the vulnerability and including a code fix. Following this, **TianoCore Project** members issued a public advisory last week. With the patch code now publicly available, it becomes significantly easier for advanced threat actors to reverse-engineer the vulnerability and develop working exploits. This urgency is compounded by the inherent difficulty and time-consuming nature of patching UEFI code across millions of devices from countless hardware makers and cloud providers. HD Moore, creator of **Metasploit** and Chief Research Officer at **Dragos**, commented on the significance: "This vulnerability in the **ICMP** parser of the **EDK2** network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem. An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s **TPM**. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario)." ### Technical Details of the Flaw **CVE-2026-97631** is a 16-year-old buffer overflow bug in the **PXE-Base Code driver** (**NetworkPkg/UefiPxeBcDxe**). This driver facilitates network booting, where devices download code from a local network. During this pre-execution environment (**PXE**) boot, the driver listens for **ICMP** errors. Critically, it fails to enforce a memory copy limit of 504 bytes. This allows a malicious insider or an attacker with low-level local network access to send an oversized **ICMP** error message, appending malicious code beyond the buffer limit and corrupting the **UEFI** module running on the **CPU**. The official advisory explains: > During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length. This malicious error can be delivered via a simple unicast to a target device's IP address during the **PXE** boot sequence. An attacker could trigger a denial-of-service or, with knowledge of the target firmware build, execute malicious code on the **CPU** within the **UEFI** environment at **ring 0**, effectively bypassing attestation processes. ### Yet Another Forever Day **CVE-2026-97631** joins a growing list of critical UEFI vulnerabilities. Recent examples include: * **LogoFail**: Stemmed from rendering bugs in logo images within **UEFI** firmware, allowing attackers to subvert the chain of trust. * **PixieFail**: A similar vulnerability also resulting from faulty **PXE** boot flaws in **EDK2**. * **PKFail**: A supply-chain issue involving non-production test platform keys used in hundreds of device models for over a decade. * **BootHole** * **Bootkit** * **BlackLotus** Like these predecessors, **CVE-2026-97631** is attractive to attackers because it enables infection early in the boot process, before **TPM** and other defenses are active. Given its ubiquity, Moore anticipates this will become a "forever bug" persisting in end-of-support systems. Exploitation of **CVE-2026-97631** does require some level of local network control, potentially limiting its use to insiders or sophisticated attackers with initial network access. Nevertheless, the broad impact and early execution capabilities make this a significant concern for IT security professionals and privacy-conscious users alike.