16-year-old buffer overflow in EDK2's PXE driver (CVE-2026-97631, CVSS 4.0 9.5) runs code before the OS on network-booting servers

TianoCore EDK II (EDK2) is the code base under most UEFI firmware — AMI, Insyde and Phoenix, the vendors that write the BIOS on the vast majority of server boards, all build on it, and so does Microsoft’s hardened fork Project Mu. Its PXE network-boot driver, NetworkPkg/UefiPxeBcDxe, carried a buffer overflow that Ars Technica calls a 16-year-old bug, disclosed on October 22, 2026 as CVE-2026-97631 and scored 9.5 under CVSS 4.0. The trigger fits in one sentence from the advisory: while a machine is PXE-booting over IPv4 or IPv6, an unauthenticated attacker who can deliver one oversized ICMP error message to its IP sends it, the message overflows a fixed 504-byte field and code can run before the operating system loads — before Secure Boot or measured boot has verified anything. The same advisory states plainly that there are “not patched currently” releases; the fix landed in master via pull request on October 15, but reaching it requires a firmware update.

Key points

• The window is narrow but the prize is high: exploitation is only possible during a PXE boot, and one ICMP error longer than 504 bytes corrupts DXE-phase memory — the listed outcomes are a hung boot (denial of OS provisioning) or attacker-supplied bytes executing at ring 0.
• Every defense loads after it: the code runs before Secure Boot verification and before the TPM measures any OS component. Eclypsium’s Jesse Michael notes that unlike BootHole or BlackLotus, the fix needs only a code patch — no key revocations, no dbx updates.
• The score splits by methodology: upstream and NVD rate 9.5 under CVSS 4.0 (AV:N, attack requirements AT:P), while Red Hat rates its own products 8.8 under CVSS 3.1 (AV:A) — the two systems weigh attack distance differently.

How the bug works

During network boot, UefiPxeBcDxe keeps a receive request open for ICMP error messages and copies each one it receives into Mode.IcmpError, a fixed 504-byte field in the driver’s private context. The advisory documents two defects working together: the copy loop’s bounds check is wrong, so messages longer than 504 bytes keep copying; and the destination pointer advances by the cumulative fragment length instead of the per-fragment length. Both the IPv4 handler (PxeBcIcmpErrorDpcHandle) and the IPv6 handler (PxeBcIcmp6ErrorDpcHandle) are affected, and nothing earlier on the receive path caps the message length.

The outcomes come in two grades. The lesser one is deterministic corruption: the driver’s private data is trashed, the next ICMP error raises a CPU exception in the DXE core, and the boot hangs — for a data center that provisions or recovers machines over PXE, that alone is a denial of service. The serious grade is code execution: an attacker who knows the target firmware build can plant a counterfeit event in the same packet and have the DXE phase’s CoreSignalEvent() dispatch attacker-supplied bytes as code, at a point where no OS-level security control exists yet.

Two words carry the real difficulty: window and tuning. The exposure lasts only as long as the PXE boot itself, and per the advisory the attacker “needs only to deliver a unicast ICMP error message addressed to the client’s IP, from any network distance” — though Ars judges that some level of control over the target’s local network is a prerequisite. Jesse Michael, principal researcher at Eclypsium, says attackers “need to guess specific addresses within the target system,” so payloads must be tuned per firmware model, version and configuration. Readers on the Ars Technica thread added one more brake: front-end load balancers (the article names Cloudflare) often block ICMP delivery, shaving the risk further.

Who is affected

EDK2’s position decides the blast radius: the BIOS vendors behind most server boards, plus Project Mu, all derive from EDK2, and Ars’s headline says the flaw “threatens most servers on planet Earth.” MITRE’s affected range runs from version 0 through edk2-stable202608 — the August 2026 stable tag is still listed. Intel said no commercial products under security support are known to be affected, though OEMs may integrate the EDK2 code themselves; Arm said the CVE “is not directly applicable to Arm’s product portfolio.” Both companies’ reference firmware borrows heavily from EDK2, and AMD, Phoenix, AMI, Microsoft and Amazon did not respond to Ars’s request for comment.

Home users can breathe halfway: only machines with PXE network boot enabled — a routine data-center provisioning configuration — are exposed. Disk-boot-only desktops and laptops are out of range, and there is no evidence the bug works as an initial entry point from the open internet. The exposed population is data-center operations, mass-provisioning environments, and the firmware supply chain.

Disclosure and the fix

The disclosure itself is a story. Per Ars Technica, the flaw was found by Alex Matrosov of Anthropic and Dan Holmes of Google, and the coordinated disclosure “scheduled for January” (Ars gives no year; since AMI’s related PR went public in late September, January 2027 is the only reading that fits the timeline) was broken early when AMI published a pull request with a code fix last month. Once the discoverers noticed, TianoCore members published the advisory on October 22 — crediting Matrosov (Anthropic) and “Dan Holmes-Mitra” (Google; Ars writes Dan Holmes) for finding the issue and providing the recommended fix. The PR that actually merged, #13302, was opened October 14 by TianoCore maintainer Michael D Kinney and merged into master October 15, with the original author’s commits preserved; it adds proper bounds checks and truncates oversized messages. In the PR comments on October 27, a community member wrote that “the embargo was violated due to a mistake, resulting in the PR being created in the open.” The GHSA still reads “not patched currently,” because no released version carries the change.

Red Hat has scored the issue for its own products at 8.8 (CVSS 3.1, AV:A), 0.7 below upstream. The disagreement is about measurement, not facts: CVSS 4.0’s AV:N says “network reachable” but its attack-requirements metric (AT:P) captures practical constraints such as catching the PXE window, while CVSS 3.1 has no such dimension and Red Hat scored it as adjacent-network. When you read reports, look at both numbers rather than quoting the bigger one.

Item	Status at disclosure (2026-10-22)	Source
CVE ID	CVE-2026-97631	MITRE / NVD
Upstream score	CVSS 4.0 9.5 (AV:N/AT:P)	GHSA
Red Hat score	CVSS 3.1 8.8 (AV:A)	Red Hat
Affected range	Through edk2-stable202608	MITRE
Fixed releases	None (merged in master; distributions pending)	GHSA
Fix PR	#13302, opened Oct 14, merged Oct 15	GitHub
Discoverers	Alex Matrosov (Anthropic), Dan Holmes (Google)	Ars

What ops should do

For anyone running servers, the advisory translates into a concrete checklist. First, inventory: which machine models provision or recover over PXE, whose firmware they run, and whether it includes the merged fix — until a vendor release ships, the master-branch patch is out of reach for deployed machines. Second, shrink the window: before firmware updates arrive, turn PXE network boot off on routinely running machines and keep it only on provisioning segments; EFI developers can carry #13302 in their own builds ahead of releases. The guidance Ars relays also includes keeping Secure Boot and the TPM enabled — neither stops this bug, and both still stop other attacks — and watching boot-related logs. The bug’s worst destiny is the one HD Moore — Metasploit’s creator and Dragos’s CRO — described: it can “hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s TPM,” disk encryption could be broken in theft scenarios, and as a “forever” bug it will live on in end-of-support machines that firmware updates never reach.

Firmware and supply-chain security has had a rough month. We covered CISA adding the exploited PHP2Shell RCE to its known-exploited catalog and Microsoft Authenticator’s zero-permission flaw going public with full technical details this week. EDK2 sits on the hardest layer of the three to patch: application vulnerabilities wait for a package update, firmware vulnerabilities wait for a BIOS release — and between them stands the whole machine vendor release cycle.