Critical UEFI Firmware Flaw Allows Attackers to Execute Malicious Code Before OS Boots

A critical vulnerability in EDK II’s PXE network boot driver could allow unauthenticated attackers to execute malicious code before the operating system loads. This vulnerability, tracked as CVE-2026-97631, affects ICMP error processing during both IPv4 and IPv6 network boot, which exposes the firmware memory to potential writes by attackers.

The advisory identifies the EDK II master as being affected as of September 14, 2026. Although the provided metadata states that no patch is available, TianoCore merged corrective changes through pull request #13302 on October 15, 2026. Whether these changes are available in individual device firmware is a separate issue.

UEFI Firmware Flaw

The vulnerability resides in NetworkPkg/UefiPxeBcDxe, the PXE Base Code driver used during the network boot process. While the machine retrieves boot resources, the driver maintains an outstanding receive request for ICMP error messages.

Received data is copied into a fixed 504-byte field called Mode.IcmpError, which is part of the driver’s private context. However, the functions PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle incorrectly handle copy boundaries.

According to the advisory, messages larger than 504 bytes can still be copied into the destination. Additionally, the fragment-handling loop advances the destination pointer using the cumulative length instead of the current fragment’s length, allowing attacker-controlled bytes to overwrite adjacent memory.

The issue follows earlier PixieFAIL vulnerabilities in EDK II’s network stack, which similarly exposed systems during network boot. Those flaws affected IPv6 processing, illustrating the security implications of firmware networking code.

The upstream fix confirms that incorrect copy logic allowed oversized packets to corrupt neighboring memory. Developers have corrected boundary checks and offset calculations, ensuring that oversized messages are truncated when the destination buffer is full.

To exploit this vulnerability, the target must be actively PXE-booting and reachable by an attacker who can deliver a unicast ICMP error message to its IP address. No authentication or user interaction is needed, but exposure is limited to the network-boot window.

The advisory outlines two potential outcomes. First, deterministic corruption of private driver data can occur, potentially triggering a CPU exception in the DXE core when another ICMP error arrives. This can hang the boot process and disrupt provisioning or recovery.

Second, an attacker familiar with the target firmware build could construct a counterfeit event that causes CoreSignalEvent() to execute attacker-supplied instructions during the Driver Execution Environment (DXE) phase.

This places execution before operating-system security controls exist. Separate research into UEFI shell flaws that disable Secure Boot demonstrates another route to compromising pre-boot protections, although the underlying mechanisms differ.

The merged patch also clears the ICMP error buffer before copying new fragments, preventing shorter messages from retaining stale data. Added unit tests cover IPv4 and IPv6 fragment packing, truncation, and TFTP buffer integrity; maintainers reported that tests failed before the correction but passed afterward.

The disclosure credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google. The vulnerability’s critical severity rating reflects the implications of unauthenticated network access and the potential for significant impacts on confidentiality, integrity, and availability. Organizations should differentiate between upstream remediation and vendor firmware availability when assessing affected systems and planning updates.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.