A severe vulnerability in the open-source EDK II UEFI firmware could allow attackers to execute arbitrary code on systems *before* the operating system loads. Identified as CVE-2026-97631, the flaw lies within the PXE (network boot) driver and was rated 9.5 under the CVSS v4 system, signaling high criticality. Many servers, desktops, and laptops that support PXE boot may be exposed because EDK II is widely used as a reference implementation for UEFI firmware.
How the exploit works
The vulnerability lives in the UefiPxeBcDxe driver. During PXE boot, this driver listens for ICMP error messages from the network and copies them into a fixed 504-byte buffer. The code fails to properly enforce size limits—both for IPv4 and IPv6 handlers—so oversized ICMP messages overflow the field. Worse, the pointer that marks where to write advances by the *total* processed length, not just the current segment, compounding the issue.
This oversight allows attacker-controlled bytes to spill beyond the buffer’s boundaries, with no earlier check on message size. Exploitation requires only a single crafted ICMP error message sent to the client’s IP *while it is PXE booting*. The attack can be carried out by anyone on the network—no authentication or user action needed—and persists so long as PXE boot is active.
Potential impact & real-world risk
The simplest consequence is a crash: the next ICMP error triggers a CPU exception inside the DXE core, causing the boot process to hang. That can block OS deployment or system recovery. But for more advanced attackers—those who know the firmware build in use—this opens the door to full privilege escalation. The exploit can allow code execution at the highest privilege, *before* features like Secure Boot or measured boot can verify integrity.
Servers are under particular threat. Data centers often rebuild machines via PXE, giving attackers repeated chances to hit vulnerable firmware during provisioning. Any system that uses network boot without proper mitigations may be at risk.
Status of fixes and mitigation steps
A patch was merged into the public EDK II code on October 15, 2026. It adds proper boundary checks, correct pointer arithmetic, zeroes out the buffer before each message, and includes unit tests to prevent regressions. However, the advisory notes that it is not yet shipped in vendor firmware updates.
Until firmware vendors deliver updates, there are temporary defense measures. Restrict PXE boot traffic to isolated provisioning networks. Block unexpected ICMP error messages aimed at booting systems. Disable PXE on machines that don’t need it. Also review broader UEFI hardening guidance, such as those from CISA and NSA concerning Secure Boot.
This flaw joins a growing list of UEFI firmware vulnerabilities—among them LogoFAIL, PKfail, and PixieFail—where attackers exploit code running prior to OS defenses. Each incident underscores the persistent risk to foundational boot components that underpin trusted computing.
Analytical takeaway: This issue highlights how code executing *before the OS* represents a critical attack surface often overlooked. As firmware stacks become more complex, vulnerabilities in network boot or pre-OS stages are increasingly promising targets. Organizations relying on PXE should assume exposure until firmware updates arrive and make isolation of provisioning networks and strict network filtering an essential part of their firmware and supply-chain security strategies. Expect firmware vendors to become a focal point for risk assessments and security audits in 2027.
