A newly disclosed vulnerability in EDK II, the open-source reference code that underpins UEFI firmware across a huge share of the server, desktop, and laptop market, allows an attacker to run malicious code on a machine before its operating system, antivirus software, or Secure Boot protections ever load. Tracked as CVE-2026-97631, the bug carries a CVSS v4 score of 9.5 and sits in the network boot, or PXE, driver that data centers rely on to install and reimage machines at scale.

A Bug in the Code That Runs Before Everything Else

EDK II is the shared codebase that many firmware vendors build on when they create UEFI firmware for their hardware. Because it is so widely reused, a flaw discovered in EDK II’s NetworkPkg component can ripple out to an enormous number of devices that have nothing else in common except booting the same reference code over a network.

The affected component, a driver called UefiPxeBcDxe, listens during a PXE boot for ICMP error messages arriving over the network and copies their contents into a fixed-size, 504-byte buffer. The flaw lies in how that copy is handled: the driver fails to properly check the size of incoming messages in both its IPv4 and IPv6 handling paths, and it advances its write position using the total amount of data received so far rather than the size of the current chunk. The result is that an oversized ICMP message can push attacker-controlled bytes past the end of the intended buffer, corrupting adjacent memory.

No Login, No User Action, Just Network Access

What makes the flaw especially dangerous is how little an attacker needs to exploit it. There is no authentication step to bypass and no action required from a victim. An attacker anywhere on the same network path simply has to send a single malformed ICMP error message to a machine while it is in the middle of a PXE boot. The only real constraint is timing: the machine has to be actively network-booting for the malicious packet to land.

Researchers describe two possible outcomes. The less severe case is a denial-of-service condition: the malformed packet triggers a processor exception inside the firmware’s Driver Execution Environment (DXE) core, freezing the boot process and blocking new installs or recovery attempts. The more serious case requires an attacker to already know the exact firmware build in use. With that knowledge, a crafted packet could be used to execute arbitrary code at the highest privilege level available on the machine, running before Secure Boot, measured boot, or any other integrity check has a chance to intervene.

Servers are considered the highest-risk category simply because of how data centers operate: PXE booting is the standard way many organizations provision or rebuild large fleets of machines, and tooling that runs automatically on every reprovisioning cycle gives an attacker repeated opportunities to strike.

Part of a Pattern in Firmware-Level Attacks

This is not an isolated event. Security researchers have flagged a recurring theme in recent years: attackers and researchers alike are increasingly focused on the earliest stages of a machine’s boot sequence, where traditional operating-system defenses have not yet loaded. Previous incidents in this space include PKfail, where device makers mistakenly shipped products using test-only cryptographic keys that were never meant to leave the lab, undermining the Secure Boot trust chain across more than 200 device models, and LogoFAIL, which exploited the code responsible for rendering a manufacturer’s startup logo to achieve code execution during the same early DXE phase. An earlier EDK II network-stack issue known as PixieFail, disclosed in 2024, affected the IPv6 stack used in the exact same network-boot scenario.

A Fix Exists, But Devices Still Need It

A corrective patch has already been merged into the public EDK II codebase, adding proper bounds checking, correcting the faulty pointer arithmetic, and clearing stale buffer contents before each new copy operation. However, the official security advisory still listed the issue as unpatched as of its publication, since merging a fix upstream and getting individual hardware vendors to incorporate it into shipped firmware updates are two very different timelines. One maintainer acknowledged that details were disclosed publicly ahead of the intended coordinated schedule, by mistake, and asked researchers to continue using private channels for future reports.

What Organizations Should Do

• Contact server and firmware vendors to ask when a patched UEFI update will be available, and prioritize installing it once released.
• Until a patch ships, isolate PXE boot traffic on dedicated, segmented provisioning networks rather than general-purpose production networks.
• Block unexpected or malformed ICMP error messages directed at machines that are actively network-booting.
• Disable PXE boot entirely on any system that does not need it.
• Review current Secure Boot hardening guidance published by CISA and the NSA for broader firmware protections.

Until vendor-specific firmware updates land, organizations that rely heavily on network provisioning should treat PXE infrastructure as a priority area for network segmentation and monitoring.