CVE-2026-97631: How a 16-Year-Old EDK II PXE Bug Exposes UEFI Firmware Before the OS Loads

CVE-2026-97631 is a memory-corruption vulnerability in the PXE network-boot code of TianoCore EDK II, the open-source reference implementation of UEFI. It carries a CVSS 4.0 score of 9.5. An unauthenticated attacker on the local network can corrupt firmware memory while a machine boots over the network, and may be able to execute arbitrary code before Secure Boot or the operating system can intervene.

The timing is what makes this serious. Before the kernel initializes its memory manager, mounts a filesystem or loads an endpoint detection agent, UEFI already controls the hardware. Its code is written mostly in C, and OS mitigations such as ASLR, stack canaries and mandatory access controls frequently do not exist at that stage.

Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google discovered the flaw, and it was disclosed publicly in October 2026. A fairly plain buffer-boundary error sat in a network-facing component for roughly sixteen years. It lives in NetworkPkg/UefiPxeBcDxe, inside the IPv4 and IPv6 ICMP error-handling routines. If an attacker delivers a crafted Internet Control Message Protocol (ICMP) error message while a vulnerable machine is booting over the network, the driver performs an out-of-bounds write and corrupts adjacent firmware memory. The outcome ranges from a denial-of-service hang during provisioning to arbitrary code execution in the UEFI Driver Execution Environment (DXE). EDK II is the codebase that hardware manufacturers and firmware developers build on, and it runs across server fleets worldwide, so the exposure is not confined to one vendor.

CVE-2026-97631 at a glance

CVE-2026-97631 is a critical vulnerability in the EDK II NetworkPkg/UefiPxeBcDxe component, which implements the UEFI PXE Base Code functionality for network booting. With a CVSS 4.0 score of 9.5, the flaw affects the IPv4 and IPv6 ICMP error handlers and is associated with CWE-120 (buffer overflow) and CWE-131 (incorrect calculation of buffer size). An unauthenticated attacker on the local network could potentially exploit the vulnerability while a target system is booting over PXE, causing a denial of service or potentially achieving arbitrary code execution within the DXE phase of UEFI firmware. Upstream fixes were introduced in EDK II changes dated October 15, 2026. The vulnerability was disclosed in October 2026 by Alex Matrosov and Dan Holmes-Mitra.

Why pre-OS firmware is so hard to defend

UEFI boots in phases: Security (SEC), Pre-EFI Initialization (PEI), the Driver Execution Environment (DXE) and Boot Device Select (BDS). DXE does most of the hardware initialization. Its drivers bring up the CPU, the memory controller, storage interfaces and network stacks, and they often run at the processor’s highest privilege level (Ring 0 on x86) with unrestricted access to physical memory and hardware I/O.

None of the operating system’s defenses exist yet. A firewall inside Linux or Windows never sees the packets that reach the vulnerable firmware, and an endpoint detection agent cannot respond to code execution that happens before the agent has loaded.

How PXE boot creates the attack surface

The Preboot Execution Environment (PXE) lets a machine start without a locally installed operating system or a bootable disk. The firmware initializes the network interface, talks to infrastructure over DHCP and TFTP, and downloads an initial program to continue booting. Enterprises use it constantly to provision large server fleets, automate operating system installs and run bare-metal recovery.

The EDK II UefiPxeBcDxe driver provides the PXE Base Code functionality, which makes it the network stack of the firmware. PXE is built to pull data from network sources that nobody has verified, so that stack is the main attack surface during boot. This is not a flaw in a long-running network service. The exposure is short, but it falls exactly when the machine is waiting for the network to tell it what to do.

How the ICMP error-handling bug works

ICMP carries diagnostic and control messages such as Destination Unreachable and Time Exceeded. Suppose a PXE client is downloading a boot image over TFTP or sending UDP traffic, and a router or intermediate host cannot deliver a packet. That device sends an ICMP error back to the source. The error contains the IP header and the first part of the payload of the packet that failed, so the receiving stack has to parse it carefully. In the EDK II PXE driver, the code must pull that diagnostic data out and store it so the PXE Base Code protocol can report the failure to the boot application.

The vulnerable routines are PxeBcIcmpErrorDpcHandle for IPv4 and PxeBcIcmp6ErrorDpcHandle for IPv6. Both copy the received ICMP error data into a field called Mode.IcmpError in the driver’s private context structure. That field is a fixed-size buffer of 504 bytes.

Fixed-size buffers are normal in firmware. Heap allocation is often avoided or tightly limited because firmware needs deterministic execution times and predictable resource use. The price is strict discipline: every write into the buffer has to respect its boundary, whatever the size or fragmentation of the incoming network data. The EDK II implementation does not, so incoming data can overwrite adjacent structures in the DXE pool.

Root cause: missing bounds enforcement and bad pointer arithmetic

The official advisory describes two logic errors in the ICMP error handlers, which together explain the CWE-120 and CWE-131 classifications. The copy operation does not stop when the 504-byte destination is full, and the destination pointer advances by a cumulative length instead of the length of the fragment just copied. Combined, they allow an out-of-bounds write that can reach far beyond the buffer.

The first error is the simpler one. A safe copy calculates the space remaining and truncates the input if necessary, so that offset plus copy length never exceeds capacity. The vulnerable code has no such stopping condition. Once the 504-byte limit is reached, the loop keeps writing attacker-controlled bytes into whatever sits next to Mode.IcmpError in the firmware’s memory pool.

The second error shows up when a message is processed in fragments. The destination offset should reflect the bytes actually copied in the current iteration. The vulnerable code instead tracks the running total across all fragments and advances the pointer by that total, so the offset grows much faster than the data.

A worked example makes the effect clear. Take three fragments of 100, 120 and 80 bytes. The cumulative lengths after each one are 100, 220 and 300. Advancing by the individual fragment lengths moves the pointer 300 bytes in total, well inside a 504-byte buffer. Advancing by the cumulative values goes like this:

1. After fragment 1 (100 bytes), the pointer advances by 100 and sits at offset 100.
2. After fragment 2 (120 bytes), it advances by the cumulative 220 and sits at offset 320.
3. After fragment 3 (80 bytes), it advances by the cumulative 300 and sits at offset 620.

Only 300 bytes of data were processed, yet the pointer is already past the end of the 504-byte buffer. The next write lands in adjacent DXE pool memory.

The C below is a conceptual sketch of the flawed logic next to a correct implementation. It is not the actual EDK II source.

/*
 * Conceptual representation of the vulnerable logic
 * Flaw 1: no boundary enforcement against the 504-byte capacity.
 * Flaw 2: the pointer advances by CumulativeLength instead of FragmentLength.
 */
UINT8 *DestPtr = Private->Mode.IcmpError;
UINTN CumulativeLength = 0;
for (UINTN i = 0; i < FragmentCount; i++) {
    CumulativeLength += Fragment[i].Length;
    CopyMem(DestPtr, Fragment[i].Data, Fragment[i].Length);
    // The pointer moves by the running total, so it leaves the buffer quickly.
    DestPtr += CumulativeLength;
}
/*
 * Conceptual representation of the secure logic
 * Enforces strict boundaries and advances the pointer correctly.
 */
UINTN Offset = 0;
UINTN BufferCapacity = sizeof(Private->Mode.IcmpError); // 504 bytes
for (UINTN i = 0; i < FragmentCount; i++) {
    UINTN RemainingSpace = BufferCapacity - Offset;
    UINTN CopyLength = Fragment[i].Length;
    // Truncate if the fragment exceeds the remaining space
    if (CopyLength > RemainingSpace) {
        CopyLength = RemainingSpace;
    }
    if (CopyLength > 0) {
        CopyMem(Private->Mode.IcmpError + Offset, Fragment[i].Data, CopyLength);
        // Advance only by the bytes actually copied in this iteration
        Offset += CopyLength;
    }
    // Stop once the buffer is full
    if (Offset >= BufferCapacity) {
        break;
    }
}

From malformed packet to code execution in DXE

The TianoCore advisory names two outcomes: denial of service and arbitrary code execution.

Denial of service is the reliable one. The malformed ICMP error corrupts the driver’s private data or an adjacent critical structure. When the DXE core later touches that memory or handles another network event, the CPU raises an exception such as a page fault or an invalid opcode, and the machine hangs or resets mid-boot. For an enterprise that provisions servers over PXE, that is a real operational disruption.

Code execution is harder, but I would not treat it as theoretical. It requires the attacker to shape the corrupted state so that firmware control flow is hijacked, and a sophisticated attacker who knows the target firmware build is the realistic candidate. DXE memory is managed in pools, and data structures are frequently allocated next to each other. If the 504-byte Mode.IcmpError buffer sits near an EFI_EVENT structure, a protocol interface or a function pointer table, the overflow can overwrite pointers that the firmware later trusts.

The advisory specifically points to dispatching a counterfeit event through CoreSignalEvent(). The EDK II DXE dispatcher is event driven: drivers register callback functions (NotifyFunctions) that run when something happens, such as a timer expiring or a packet arriving, and CoreSignalEvent() walks the registered events and runs their callbacks. Overwriting the NotifyFunction pointer of an adjacent event structure would redirect execution. UEFI firmware has historically lacked universal ASLR and relies on deterministic memory layouts to stay compatible with legacy Option ROMs, so addresses of such structures are often predictable. The result would be ring-0 code execution before the operating system kernel is read from disk. That last step is my inference from the advisory’s description, not a demonstrated exploit.

Why Secure Boot and the TPM do not stop CVE-2026-97631

Many enterprises assume that Secure Boot and the Trusted Platform Module (TPM) make pre-OS bugs irrelevant. CVE-2026-97631 shows where that assumption fails.

Secure Boot verifies the cryptographic authenticity of boot components, such as shim, GRUB or the Windows Boot Manager, against the platform’s trust databases (db, KEK, PK). Only signed executables get to run. It does not check the integrity of the DXE environment at runtime. The vulnerable PXE driver is a signed, legitimate part of the firmware, and when it processes the malicious ICMP packet and corrupts memory, Secure Boot has no way to notice. The attack abuses the runtime behavior of trusted code, which static signature verification cannot catch.

The TPM and Measured Boot do something different from what many people expect. Measured Boot records hashes of boot components by extending them into Platform Configuration Registers (PCRs), which lets you prove after the fact what code was loaded. It attests; it does not prevent. A TPM cannot stop instructions from running inside a vulnerable firmware driver, and it cannot watch the heap for corruption.

An attacker who reaches code execution through CVE-2026-97631 operates in DXE with privileges above the operating system. From there they could hook EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to intercept the OS kernel as it loads, inject a rootkit before OS defenses start, or try to disturb the trust relationship between the TPM and disk encryption such as BitLocker or LUKS. The TPM might eventually record a measurement showing the boot state drifted from baseline, but by then a persistent firmware rootkit could be installed or credentials exfiltrated.

Why an upstream EDK II patch does not mean patched servers

The upstream EDK II history records corrective changes on October 15, 2026. They address the buffer overflow, the offset calculations and the truncation of oversized messages. A merged patch is only the first step, though. EDK II is a reference codebase that manufacturers fork, modify heavily and combine with proprietary silicon initialization code. The firmware on a bare-metal server is a mix of upstream open-source code, vendor drivers and OEM customizations, and no central package manager updates it.

Firmware integrators have to work through a long list. They must determine whether their products contain the affected component, merge the upstream fix, validate it against their own hardware configurations, then build, sign and distribute BIOS/UEFI update capsules. A fix in a development branch is not a signed BIOS update that you can download. As of the October 22, 2026 advisory, the patched-version field for many downstream implementations is still unresolved.

There is also a history here. PixieFail, a set of nine vulnerabilities in the EDK II network stack, was disclosed in early 2024 and triggered large fuzzing campaigns and security reviews of NetworkPkg. CVE-2026-97631 survived all of that. State-dependent logic errors involving arithmetic and fragment reassembly in code that is more than a decade old are exactly the kind of bug that fuzzing and review can miss.

How to mitigate CVE-2026-97631 until vendor patches ship

Until vendors release validated, signed firmware that includes the October 2026 fixes, the defenses are architectural.

• Disable PXE boot in firmware settings on every machine that does not need network provisioning. If a server boots only from local NVMe or a SAN, turn off the PXE Option ROM or UEFI network stack and the attack surface leaves the boot sequence.
• Isolate PXE networks where PXE is required. Use management VLANs with no route to the general corporate network or the internet, restrict access to the DHCP and TFTP services PXE depends on, and limit which systems can send traffic to machines during the boot window.
• Monitor for anomalous ICMP error messages from unauthorized internal sources during provisioning windows. Filtering ICMP entirely can break legitimate diagnostics, so treat monitoring as a supplement to segmentation.
• Inventory firmware versions and boot configurations, and separate physical bare-metal servers from virtual machines, because the hypervisor supplies firmware to VMs.
• Ask each hardware vendor whether your products include the UefiPxeBcDxe driver and when patched BIOS releases will arrive.
• Keep Secure Boot and Measured Boot enabled. They will not stop the initial memory corruption, but they make it harder for an attacker to persist across reboots or load unauthorized later boot stages.

What CVE-2026-97631 means for UEFI firmware security

The boot process is a complex C codebase, and it has the same memory-safety problems as any other. A sixteen-year-old arithmetic error in an ICMP handler was enough to undercut hardware security features that organizations spent heavily on. Fixing it takes more than a code commit: the change has to travel through the whole hardware supply chain before it reaches the silicon of a production server.

Firmware needs the same adversarial testing, input validation and memory-safety scrutiny as the operating systems and applications that run above it. Until the UEFI ecosystem moves to memory-safe languages or enforces modern exploit mitigations everywhere, similar bugs will keep turning up in pre-OS code. For now, the practical step is to check which of your machines boot over PXE and which vendors have not yet named a patched version.

Frequently asked questions about CVE-2026-97631

What is CVE-2026-97631?

It is a critical memory-corruption vulnerability (CVSS 4.0 score of 9.5) in the PXE Base Code driver of TianoCore EDK II. Faulty ICMP error handling lets an unauthenticated attacker on the local network write past a 504-byte buffer during network boot.

Does Secure Boot protect against CVE-2026-97631?

No. Secure Boot checks the signatures of boot components but does not monitor the runtime integrity of DXE. The vulnerable driver is signed and trusted, and the attack abuses its behavior at runtime.

Is there a patch for CVE-2026-97631?

Upstream EDK II received fixes on October 15, 2026. Many downstream vendors had not listed a patched version as of the October 22, 2026 advisory, so you need to check with each hardware vendor for a signed BIOS or UEFI update.

How can I reduce my exposure to CVE-2026-97631 now?

Disable PXE boot on machines that do not need it, isolate PXE networks on restricted management VLANs, monitor for unusual ICMP errors during provisioning, and ask your vendors whether your firmware includes UefiPxeBcDxe.