A critical 16-year-old flaw has been discovered in **EDK II**, the foundational open-source code used by most hardware manufacturers to build **UEFI** firmware. This vulnerability, designated **CVE-2026-97631**, allows an attacker to execute code on a machine before its operating system loads, but only when the machine is booting over the network. **UEFI** firmware is the initial software that runs upon computer startup, preceding the operating system. An attacker able to reach the target machine with a specially crafted network message during a network boot can either halt the boot process or, with a tailored exploit for the specific firmware build, run their own code before **Secure Boot** and other startup defenses are activated. Crucially, this exploit requires no password or existing access to the machine. However, it does necessitate network access during the brief window when the machine is performing a network boot. **Red Hat** and **SUSE**, both shipping affected code, have classified this as an adjacent network attack, rather than one exploitable across the open internet. **TianoCore**, the project behind **EDK II**, published an advisory on October 22, rating **CVE-2026-97631** with a severity of 9.5 out of 10. A code fix is available, but no stable release of **EDK II** currently incorporates it, leaving most users without an immediate patch. ### The Nature of the Flaw The vulnerability is a buffer overflow within **EDK II**'s network-boot code, specifically the **PXE** (Preboot eXecution Environment) driver. During a **PXE** boot, a machine loads its startup image from the network instead of a local disk. As part of this process, the **PXE** driver listens for **ICMP** error messages and small status messages from network devices, copying each into a fixed 504-byte memory area. The size checks within both the IPv4 and IPv6 versions of this copy function are incorrect. This allows a message longer than 504 bytes to spill past the allocated buffer, overwriting adjacent memory with attacker-controlled data. To trigger this, an attacker merely needs to send a single crafted error message to the machine's address while it is in the midst of a network boot. No authentication or prior access is required. The simplest outcome is a crash, causing the boot to hang and the machine to fail to start. Achieving code execution is significantly more complex and less reliable. The advisory notes that an attacker with precise knowledge of the firmware build could plant a "counterfeit event" to compel the firmware to execute their code, implying exploits must be built for specific firmware versions. When code is successfully executed this way, it runs within the firmware context, prior to **Secure Boot** and other boot-time verification mechanisms. This timing is what elevates the flaw's severity. While code planted in this manner runs only once and does not persist across reboots by itself, that single execution is sufficient to install persistent malicious code. ### Affected Systems and Products The bug exists in **EDK II** versions up to and including `edk2-stable202608`, the newest stable version dated August 21. As **EDK II** serves as the reference code for nearly all **UEFI** firmware vendors, including independent **BIOS** makers like **AMI**, **Insyde**, and **Phoenix**, as well as **Microsoft**'s hardened fork, **Project Mu**, the potential impact is widespread. The flawed copy loop has been present in the code since a commit in November 2010. **PXE** network boot is enabled by default in **EDK II**'s standard build. The flaw does not affect typical home or office users who boot exclusively from local disks. Its primary impact is on organizations whose machines, predominantly servers and data center equipment, rely on network booting. The exact number of shipping products containing the vulnerable code remains unknown. **Intel** stated that none of its "commercial products currently under security support" are known to be affected, and that it "does not include the affected **EDK2** functionality in its reference code," though an **OEM** board or system vendor could integrate it. **Arm** also indicated the flaw "is not directly applicable to Arm's product portfolio," despite both companies' firmware drawing on **EDK II**. Linux distributions also ship the code. **Red Hat** lists its `edk2` package in **Red Hat Enterprise Linux 8, 9, and 10** as affected and currently unpatched. **SUSE** and **Debian** have similarly marked their equivalent packages. **AMD**, **Phoenix Technologies**, **AMI**, **Microsoft**, and **Amazon** did not respond to inquiries before publication, leaving the status of their products unclear. ### Patching and Mitigation Strategies A fix has been merged into the **EDK II** source code, addressing the faulty copy operation to truncate oversized messages at 504 bytes instead of allowing overflow. This fix reached the main development branch on October 15. However, no stable **EDK II** release yet includes this fix. The newest stable version, `edk2-stable202608`, predates it, and the official advisory still lists the patched version as "Not patched currently." Notably, **Microsoft**'s **Project Mu** has already incorporated the fix into its release branches, with tagged builds cut on October 26. Even with the fix publicly available in source code, server operators must await a **BIOS** or **UEFI** update from their firmware vendor. Jesse Michael, a principal researcher at firmware security firm **Eclypsium**, noted that unlike **Secure Boot** bypasses such as **BootHole** and **BlackLotus**, this flaw "can be fixed with a basic code fix" and does not necessitate certificate or key revocations, simplifying the deployment process. Until an official update arrives, the advisory offers no specific workaround. However, since the flaw is only reachable during a network boot, organizations that do not require **PXE** can disable it to reduce their attack surface. Monitoring boot-time network traffic and logs for suspicious activity is also advised. ### Disclosure and Impact The flaw was discovered by Alex Matrosov of **Anthropic** and Dan Holmes-Mitra of **Google**. A coordinated disclosure was initially planned for January 2027. This timeline was accelerated when a pull request to **EDK II**, signed off by an **AMI** engineer, publicly described the flaw by its **CVE** number and included the fix on September 28. Upon seeing this public disclosure, **TianoCore** released its advisory on October 22, weeks ahead of schedule. With the patch now public, skilled attackers can analyze it to understand the flaw and potentially develop exploits. There is currently no evidence that the flaw has been actively exploited. It was not listed in **CISA**'s Known Exploited Vulnerabilities catalog as of its October 27 update, and no researcher has reported observing exploitation. The flaw is not, on its own, a direct path into a network. Firmware researchers suggest that the realistic attacker is likely an insider, or someone who has already established a low-level foothold on the local network and seeks to deepen their access. HD Moore, creator of **Metasploit** and Chief Research Officer at **Dragos**, commented that "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**." He added, "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)." This is not the first serious flaw found in **EDK II**'s network-boot code. In January 2024, researchers disclosed **PixieFail**, a set of nine vulnerabilities in the same part of **EDK II**, also exploitable during **PXE** boot. Interestingly, fuzzing projects initiated after **PixieFail** to uncover more bugs in the code did not detect this particular vulnerability.