CVE-2026-97631: The UEFI PXE Boot Flaw

Quick verdict: CVE-2026-97631 is a critical pre-boot flaw in TianoCore EDK II’s PXE Base Code driver. An unauthenticated attacker who can send a crafted ICMP error message to a machine while it is PXE-booting can write past a fixed 504-byte buffer in DXE memory. The deterministic result is a boot hang. With knowledge of the target firmware build, the same packet can plant a counterfeit event and run attacker-supplied code in DXE, before the operating system loads and before Secure Boot or measured boot has verified anything. The code is widespread. The attack window is not: the machine must be network-booting, and the attacker must be able to reach its IP with ICMP errors.

The advisory, GHSA-99cj-7hg9-mp4m, was published October 22, 2026, the same day as the NVD record. Ars Technica covered it on October 27 under the headline "Code-execution flaw in UEFI firmware threatens most servers on planet Earth." The headline is directionally right about the code’s reach and too broad about the exposure. This post separates the two.

What the bug is

Sponsored

Tired of "file too large" and broken links when sending to the world and to China? Sesame Disk by NiHao Cloud Upload once, share anywhere — China, USA, Europe, APAC. Pay only for what you use.

EDK II’s PXE Base Code driver, NetworkPkg/UefiPxeBcDxe, handles network boot. While a machine is PXE-booting over IPv4 or IPv6, the driver keeps a receive request open for ICMP error messages and copies each message into a fixed 504-byte field, Mode.IcmpError, in its private context structure. The copy loop’s bounds handling is wrong in both the IPv4 and IPv6 handlers, PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle. A message longer than 504 bytes is still copied, and the destination pointer advances by the cumulative rather than the per-fragment length. The result is an out-of-bounds write of attacker-controlled bytes.

The advisory maps the flaw to CWE-120 (classic buffer overflow), CWE-131 (incorrect calculation of buffer size), and CWE-787 (out-of-bounds write). NVD’s description adds arbitrary code execution and impact to confidentiality, integrity, and availability. The GHSA rates it CVSS v4.0 9.5, with the vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The AT:P term is the formal way of saying that attack requirements are present: the target must be in the vulnerable state, which here means PXE-booting.

The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google for finding the issue and providing the recommended fix.

The attack window is the story

The advisory is explicit about the precondition. The attacker needs only to deliver a unicast ICMP error message addressed to the client’s IP, from any network distance. The exposure window is the duration of the PXE boot. A server that boots from local disk is not in that window. A provisioning network that uses PXE is.

"From any network distance" does not mean the internet is exposed. The packet still has to reach the client’s IP, and the client has to be in the middle of a network boot. The practical question is therefore not "do we own servers?" It is "which machines PXE-boot, on which segments, and who can send ICMP into those segments?"

Condition	Why it matters
Machine is PXE-booting over IPv4 or IPv6	The vulnerable receive request is open only during network boot.
Attacker can deliver a unicast ICMP error to the client’s IP	That is the packet that reaches the flawed copy loop.
Attacker knows the target firmware build	Needed for the code-execution variant, not for the deterministic boot hang.
Machine boots from local disk	Outside the PXE path described in the advisory.

What the attacker gets

The advisory describes two outcomes. The first is deterministic: corruption of the driver’s private data and a CPU exception in the DXE core on the next ICMP error, which hangs the boot. That is a denial of service against OS provisioning or recovery.

The second requires more. An attacker who knows the target firmware build can plant a counterfeit event in the same packet and have CoreSignalEvent() dispatch attacker-supplied bytes in DXE. That is ring 0 before any OS security control exists, and before Secure Boot or measured boot has verified or measured an OS component. The advisory does not claim persistence or a post-boot implant; the impact is pre-boot code execution.

The advisory does not report in-the-wild exploitation, and the coverage reviewed for this post does not cite a public proof-of-concept. The absence of a public exploit does not lower the severity, but it does affect the immediate threat model: this is a vulnerability to patch and segment, not a worm observed in production.

Patch status: upstream fix, no customer-ready version

The upstream fix is PR #13302. The advisory still lists "Not patched currently" and does not document a workaround. That phrasing is about the advisory’s package metadata, not about the code: the fix exists upstream, but a patched EDK II build is not the same as a patched server. Each firmware vendor and OEM has to integrate it and ship an update. NVD’s record is marked "Deferred" for enrichment, so the GHSA is the primary technical reference.

The affected version in the advisory is EDK II master as of September 14, 2026. Ars Technica describes EDK II as boot-time firmware used by most of the world’s server vendors and data centers, and describes the flaw as a 16-year-old buffer overflow. That reach is why the headline says "most servers." It is also why the fix has to come from each vendor rather than from a single upstream commit.

What to do until firmware updates ship

Remove the PXE path where it is not needed. Disable network boot on machines that boot from local disk. The vulnerability is in the PXE boot path; removing the path removes the exposure. This is the closest thing to a workaround the advisory does not provide.
Isolate provisioning networks. Restrict which hosts can send ICMP errors to machines that are PXE-booting, and do not expose the boot segment to untrusted networks.
Shorten the window. Reserve network boot for scheduled provisioning and recovery, and boot from local disk otherwise.
Track vendor advisories. Ask your firmware vendor for the EDK II fix in its next release. The upstream pull request is not a customer-ready update.
Watch for boot hangs. A deterministic crash during PXE boot is the low-noise symptom. Investigate repeated provisioning failures on the same segment.

What the headline gets right and wrong

Ars Technica’s "most servers on planet Earth" captures the code’s reach. EDK II is foundational, and the bug is old. The headline does not capture the precondition: a server that is not PXE-booting is not exploitable by this path. The useful takeaway is not "every server is at risk." It is "every PXE-boot path needs a firmware fix and a network boundary." That is a smaller population, and a more actionable one.

Timeline

Date	Event
October 22, 2026	GHSA-99cj-7hg9-mp4m and NVD publish CVE-2026-97631.
October 27, 2026	Ars Technica and security press cover the flaw.
October 28, 2026	Advisory still lists no patched version; upstream fix is PR #13302.