The critical buffer overflow vulnerability CVE-2026-97631 in the EDK II PXE driver — the open-source codebase underlying the UEFI firmware of most server and client platforms — allows an unauthenticated attacker to execute arbitrary code before the operating system loads and before Secure Boot is enforced. The vulnerability affects systems that use PXE network boot and is rated 9.5 on the CVSS v4 scale (Critical). The fix has been committed to the EDK II source code, but no stable release includes it yet, and operators of server infrastructure with PXE boot are advised to disable network boot until firmware updates are available.
Technical details of the vulnerability
The vulnerability is classified as an out-of-bounds write (CWE-787) in the NetworkPkg/UefiPxeBcDxe component — the EDK II PXE driver. PXE (Preboot Execution Environment) is a mechanism for booting a machine over the network, widely used in data centers for server deployment and recovery.
During PXE boot, the driver processes incoming ICMP error messages, copying their contents into a fixed 504-byte memory region. Bounds checks in this copy operation are implemented incorrectly for both IPv4 and IPv6. Sending a specially crafted ICMP packet larger than 504 bytes leads to adjacent memory regions being overwritten with data controlled by the attacker.
Exploitation does not require a password or prior access to the system — it is enough to be able to send a network packet to the machine’s address at the moment of PXE boot. At the same time, according to the CVE record, Red Hat and SUSE classify the attack vector as reachable from an adjacent network segment rather than from the open internet.
The guaranteed result of exploitation is boot failure (denial of service). Achieving arbitrary code execution is significantly more difficult: it requires knowledge of the specific firmware build of the target system and development of an exploit tailored to it. A universal exploit for a mass attack is unlikely precisely because of this configuration dependence.
It is worth noting the differences in severity assessments from various sources: TianoCore assigns a score of 9.5 under CVSS v4, while SUSE rates the vulnerability at 8.8 under CVSS v3 (Important). This is not a contradiction — the discrepancy is due to different versions of the CVSS methodology; SUSE also displays the CNA score of 9.5 under CVSS v4.
Scope of affected systems
The vulnerable code has been present in EDK II since the November 2010 commit, meaning it has existed for about 16 years. All versions of EDK II up to and including edk2-stable202608 (dated 21 August 2026) are affected.
EDK II is a reference codebase used by major UEFI firmware vendors (AMI, Insyde, Phoenix), as well as by Microsoft in the Project Mu initiative. However, widespread use of EDK II in the ecosystem does not mean that all servers are vulnerable. Practical exposure is determined by the intersection of three conditions:
- The EDK II PXE driver is present in the system firmware;
- The system is actually performing a network boot at the moment of the attack;
- The attacker can deliver ICMP traffic to the machine’s address at that moment.
Home and office computers that boot from a local disk are not affected. The main risk group consists of servers and data center equipment that use PXE for deployment.
Among Linux distributions, Red Hat lists edk2 packages in RHEL 8, 9, and 10 as affected and not yet fixed; Debian records the vulnerability in the bookworm, trixie, forky, and sid packages. We have previously written about vulnerabilities in the Red Hat ecosystem, and this case once again highlights how heavily corporate Linux distributions depend on shared components.
According to Ars Technica, Intel has stated that none of its supported commercial products are affected, although OEM manufacturers may have integrated the vulnerable component independently. Arm has reported that the vulnerability does not apply to its product portfolio. The status of products from AMD, Phoenix Technologies, AMI, Microsoft, and Amazon remains unknown at the time of publication.
Patch status and disclosure timeline
The fix was committed to the EDK II main branch on 15 October 2026. The patch rewrites the copy operation so that packets larger than 504 bytes are truncated instead of being written beyond the buffer boundaries. However, no stable EDK II release includes this patch yet — the latest edk2-stable202608 release is dated 21 August, and in the TianoCore advisory a version with the fix is still listed as unavailable. According to Ars Technica, Microsoft Project Mu integrated the fix into its release branches on 26 October.
The vulnerability was discovered by Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google). Coordinated disclosure was planned for January 2027, but on 28 September a pull request from an AMI engineer publicly described the vulnerability, referenced the CVE number, and contained the fix. After that, TianoCore published its advisory on 22 October — several weeks ahead of schedule. The public availability of the patch means that capable attackers can study it to create exploits.
No evidence of active exploitation has been found so far. The vulnerability has not been added to the CISA KEV catalog.
Recommendations
The key priority is not to wait for operating system package updates but to track firmware updates from the hardware vendor, since it is the firmware vendor who must release a BIOS/UEFI update based on the corrected EDK II code. Until such an update appears:
- Disable PXE boot on all systems where network boot is not necessary for business processes;
- Monitor network traffic in segments where PXE boot is used, paying attention to anomalous ICMP packets at the moment servers are booting;
- Contact the manufacturer of the server hardware or motherboard to clarify exposure status and the timeline for a firmware update;
- Restrict network access to segments with PXE boot, minimizing the ability to send arbitrary traffic from adjacent networks.
An important practical point: unlike Secure Boot bypass vulnerabilities such as BootHole and BlackLotus, CVE-2026-97631 is remediated by a regular code update and does not require revocation of certificates or keys, which simplifies the patching process once updates are available.
Organizations operating server infrastructure with PXE boot should already be inventorying systems with an active network bootloader, disabling PXE where it is not critical, and logging a request with their firmware vendor — there is still no stable EDK II release with the fix, and the timelines for it to appear in specific products depend on each individual manufacturer.
