UEFI PXE Boot Flaw: What CVE-2026-97631 Means for Servers

By Jaspal Singh October 29, 2026 Updated: October 29, 2026

CVE-2026-97631 is a critical buffer overflow in the network-boot (PXE) driver of EDK II, the open-source code behind most server UEFI firmware. While a machine boots over the network, one oversized ICMP error message can hang it or run attacker code before the operating system and Secure Boot checks load. Machines that boot only from local disk are not exposed.

What Happened

On 22 October 2026, the TianoCore project, which maintains EDK II, published security advisory GHSA-99cj-7hg9-mp4m, titled "Pre-boot RCE in EDK II PXE driver." It rates the flaw critical, with a CVSS 4.0 score of 9.5 out of 10, and classifies it as a classic buffer overflow, an incorrect buffer-size calculation and an out-of-bounds write. The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google with finding the bug and supplying the recommended fix.

The disclosure came months earlier than planned. According to Ars Technica's reporting, also published by Wired, the researchers had arranged a coordinated release for January 2027. Then, on 28 September, a public pull request to the EDK II repository named the CVE and contained the code fix; Ars attributes that change to AMI, one of the large firmware vendors. That pull request was closed without being merged. Once the discoverers saw it, TianoCore published its advisory.

The fix that did land is pull request #13302, opened on 14 October and merged into the EDK II main branch on 15 October, with unit tests that fail before the change and pass after it. The advisory still lists the affected range as "EDK II master as of 2026-09-14" and says the code is "not patched currently," meaning no stable EDK II release contains the fix yet. Microsoft's Project Mu, a hardened EDK II fork, backported the fix in mu_basecore release v2026080000.0.5 on 26 October, and in an older release branch on 28 October.

There is no public sign of attacks so far. As of 29 October, the bug does not appear in CISA's Known Exploited Vulnerabilities catalogue. According to The Hacker News, Red Hat, SUSE and Debian list their EDK II packages, the firmware used to boot many virtual machines, as affected and not yet fixed.

Why It Matters

EDK II is not one vendor's product. It is the shared reference code that independent BIOS vendors such as AMI, Insyde and Phoenix build on, and that server makers and cloud providers then customise. A bug in it can therefore sit inside firmware from hundreds of hardware brands at once. Ars describes the vulnerable code as about 16 years old, so it is present in machines that will never receive another firmware update.

The location of the bug is what makes it serious. Code that runs during the UEFI boot phase runs before the operating system, before endpoint protection, and before the checks that Secure Boot and measured boot perform on OS components. Anything planted there is invisible to tools running inside Windows or Linux. HD Moore, chief research officer at Dragos, told Ars that an attacker could use the bug to take over the boot process while it still has access to the TPM, which could help break disk encryption on a machine the attacker can reach on the network, and more easily on a stolen one.

The early leak also changes the patching race. With the fix public, skilled attackers can compare the old and new code to see exactly how to trigger the overflow. Fixing it in the field takes longer than fixing it upstream: each firmware vendor must take the change, each server maker must build and test a new BIOS image, and each operator must flash it, often with a maintenance window and a reboot.

How It Works

PXE, the Preboot Execution Environment, lets a machine with no usable operating system ask the network for one. It is how data centres install systems on thousands of servers at once, how diskless machines start, and how many recovery and reimaging tools work. During a PXE boot, the firmware's PXE Base Code driver (the NetworkPkg/UefiPxeBcDxe module) gets an address, downloads a boot program and runs it.

While it does that, the driver keeps a listener open for ICMP error messages. These are the small "destination unreachable" style notices that routers and hosts send when a packet cannot be delivered. The driver copies each one it receives into a fixed 504-byte field called Mode.IcmpError.

The advisory explains that the copy loop gets its bounds wrong in both the IPv4 handler and the IPv6 handler. Two mistakes combine:

For a message longer than 504 bytes, the loop keeps copying instead of stopping at the end of the field.
When a message arrives in fragments, the loop moves its write position forward by the total length so far rather than by the length of the current fragment, so later pieces land further and further past the field.

Nothing earlier in the receive path limits the message size, so an attacker's bytes overwrite whatever memory sits next to the field. The advisory lists two outcomes. The simple one is a crash: the driver's private data is corrupted and the next ICMP error triggers a CPU exception, hanging the boot. The dangerous one needs the attacker to know the exact firmware build. In that case the same packet can plant a counterfeit event structure, and the firmware's own event dispatcher then runs the attacker's bytes during the DXE phase, at ring 0, the processor's most privileged level for that environment.

The packet only has to be a unicast ICMP error addressed to the target's IP address, and the advisory says it can come "from any network distance." The window is narrow, though: only the seconds or minutes the machine spends in PXE boot.

Researchers quoted by Ars add practical limits. Jesse Michael of Eclypsium said exploits need specific memory addresses that change with each model, version and configuration, so one exploit will not work across a mixed fleet. An attacker also needs enough position on the network to know when a target is PXE-booting and to reach it, which points to insiders or intruders who are already inside. A payload delivered this way does not persist by itself, but it runs early enough to install something that does. Michael also said the bug "can be fixed with a basic code fix," with no need to revoke Secure Boot keys, which makes it simpler to remediate than earlier boot-level flaws.

What's Still Unknown

The biggest open question is which shipping products include the vulnerable driver. Intel told Ars it knows of no supported commercial Intel product affected, though device makers that use its reference code could add the module. Arm said the flaw does not directly apply to its products. AMD, AMI, Phoenix, Microsoft and Amazon did not answer Ars's questions, so their exposure and timelines are unconfirmed.

It is also unclear when server makers will ship BIOS updates, or whether older models will get one at all. Moore told Ars the flaw is likely to become a "forever" bug on end-of-support hardware. Nor is it known when a stable EDK II release will carry the fix, which matters for the many projects that pick up only tagged releases. Finally, no one has shown a working public exploit, and there is no report of use in attacks, but both can change quickly now that the fix is visible.

Until updates arrive, the practical steps start with the one Ars recommends, turning off network boot on machines that do not need it and watching logs for exploit attempts. Beyond that: move local disk ahead of PXE in the boot order, keep provisioning on a separate, tightly controlled network segment, and watch for firmware updates from your server maker and hypervisor or Linux vendor.

Frequently Asked Questions

What is CVE-2026-97631?

CVE-2026-97631 is a critical buffer overflow in the PXE network-boot driver of EDK II, the open-source UEFI firmware code used by most server firmware vendors. A malformed ICMP error message sent while a machine boots over the network can overflow a 504-byte buffer, hanging the boot or, with knowledge of the exact firmware build, running attacker code before the operating system starts.

Is my home PC or laptop affected?

Probably not in practice. The flaw can only be reached while a machine is booting from the network over PXE. Most home PCs and laptops boot from their internal drive, and network boot is usually switched off or placed last in the boot order. Machines that boot only from local disk are not exposed, although a firmware update is still worth installing when your maker offers one.

Who is most at risk from this UEFI flaw?

Organisations that use network boot heavily face the most risk: data centres that provision servers over PXE, cloud and hosting providers, labs with diskless machines, and companies that reimage PCs from the network. Virtual machines can be affected too, because Red Hat, SUSE and Debian list their EDK II packages, the firmware used to boot many virtual machines, as vulnerable.

Can attackers exploit it over the internet?

The advisory says the malicious packet can come from any network distance, but the attack only works during the short window when the target is PXE-booting, and the attacker must know when that is. Researchers told Ars Technica that exploitation realistically needs some control of the local network, so it suits insiders or intruders who have already gained a foothold.

Does Secure Boot protect against CVE-2026-97631?

No. The overflow happens inside the firmware's own network driver, before Secure Boot or measured boot has verified or measured any operating system component. Code run through the bug executes in the firmware environment at the processor's most privileged level, so it can tamper with the boot process before those protections have anything to check. Patched firmware is the real fix.

Is there a patch for the EDK II PXE vulnerability?

The fix was merged into the EDK II main branch on 15 October 2026, and Microsoft's Project Mu shipped it in releases on 26 and 28 October. No stable EDK II release includes it yet, and most operators cannot apply source code directly. They need a BIOS or UEFI update from their server or motherboard maker, or an updated firmware package from their Linux or hypervisor vendor.

What should I do until my server maker ships an update?

Disable PXE network boot on machines that do not need it, and put local disk ahead of network boot in the boot order. Where PXE is essential, keep provisioning traffic on an isolated, monitored network segment so outsiders cannot reach booting machines. Track your vendor's security bulletins for a BIOS update, and plan a maintenance window to flash it once available.

Why was the bug disclosed early?

The researchers had planned a coordinated disclosure for January 2027. According to Ars Technica, a public pull request attributed to firmware maker AMI appeared on 28 September naming the CVE and including the fix, which effectively revealed the bug. TianoCore then published its advisory on 22 October, so defenders would at least hear about the flaw at the same time as attackers.