CVE-2026-97631: a 16-year-old EDK II bug with no stable fix yet

A 16-year-old buffer overflow in EDK II, the open-source code most hardware makers use to build UEFI firmware, can let an attacker run code before the operating system loads, and before Secure Boot has checked anything. The flaw, tracked as CVE-2026-97631 and rated 9.5 out of 10 by TianoCore, only bites while a machine is booting over the network. But the fix has not yet reached a stable release, so for most operators there is currently nothing to install.

The headline numbers

What the data actually shows

The mechanics are simple, which is part of the problem. During a PXE boot, where a machine loads its startup image from the network rather than a local disk, the PXE driver keeps a receive request open for ICMP error messages, the small status messages network devices send back. Each one is copied into a fixed 504-byte field. The bounds handling is wrong in both the IPv4 and IPv6 handlers, so an oversized message still gets copied and spills attacker-controlled bytes past the field. Nothing earlier on the receive path limits the message length.

The result splits into two outcomes of very different difficulty. The easy one is a crash: a CPU exception inside the DXE core, the firmware phase that loads drivers, and a hung boot. That is a denial of OS provisioning or recovery, which matters to anyone rebuilding servers over the network after an incident. The hard one is code execution. The advisory says an attacker who knows the exact firmware build can plant a counterfeit event in the same packet and have the firmware dispatch attacker-supplied bytes at ring 0, before any OS security control exists. Exploits therefore have to be built for a specific firmware build.

The reach is also notable. The attacker needs no password and no prior access, only the ability to deliver a unicast ICMP error to the client's address during the boot window. The advisory says the attacker can deliver the message "from any network distance", while Red Hat and SUSE rate it as exploitable from an adjacent network position.

Code run this way executes once and does not survive a reboot on its own. Even so, a single run is enough to install something that does start on every boot.

What the data does not tell us

The biggest gap is exposure. How many shipping products carry the vulnerable code is not known. PXE network boot is on by default in EDK II's standard build, and the flaw sits in versions up to and including edk2-stable202608, but individual vendors can and do change what they ship.

Vendor positions are patchy. Intel told Ars Technica that none of its commercial products currently under security support are known to be affected and that it does not include the affected EDK2 functionality in its reference code, though an OEM board vendor or system maker could add it. Arm said the flaw is not directly applicable to its product portfolio. AMD, Phoenix Technologies, AMI, Microsoft and Amazon did not answer questions before publication, and TianoCore did not respond either. For the firmware makers that matter most, the status is simply unconfirmed.

Exploitation evidence is thin in both directions. The flaw was not in CISA's Known Exploited Vulnerabilities catalogue as of its 27 October update, and no researcher has reported seeing it used. Absence of reports is not proof of absence, particularly for an attack that executes before the OS loads.

How this compares

The disclosure did not go to plan. The finders, Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, had a coordinated disclosure pencilled in for January 2027. That was overtaken on 28 September, when a pull request signed off by an AMI engineer publicly described the flaw by CVE number and included the fix. TianoCore published its advisory weeks early. With the patch public, skilled attackers can study it to work out how the flaw is triggered and build working exploits.

Against better-known firmware problems, the remediation path looks easier. Jesse Michael, a principal researcher at Eclypsium, told Ars Technica that unlike Secure Boot bypasses such as BootHole and BlackLotus, this flaw "can be fixed with a basic code fix" and does not need certificate or key revocations. Firmware makers still have to ship the fix. Microsoft's Project Mu cut tagged builds with the fix on 26 October, while upstream EDK II had no stable tag containing it when The Hacker News checked on 28 October. The same pattern of a known flaw outrunning shippable fixes appears elsewhere, as with the Parallels bug where Intel Macs cannot install the fix and the DIR-822A router flaw with public exploit code and no patch.

So what?

For UK and US IT teams, the exposed population is anyone running servers or data centre kit that boots over the network. Red Hat lists its edk2 package in RHEL 8, 9 and 10 as affected and not yet fixed, and SUSE and Debian mark their equivalent packages the same way, and no fix has yet shipped for those packages.

Practical steps follow from the facts:

• Inventory which machines actually use PXE. Where network boot is not needed, disable it; the flaw is only reachable during a network boot.
• Watch boot-time network traffic and logs for signs of attempts, as Ars advised, and treat unexpected ICMP error traffic aimed at booting hosts as worth investigating.
• Ask firmware and server vendors directly whether their builds include the PXE Base Code driver and when a BIOS or UEFI update built from the fix will ship.

Frequently asked questions

Who is affected by CVE-2026-97631?

Organisations whose machines boot over the network using PXE, mainly servers and data centre equipment. Home and office machines that boot only from a local disk are not affected.

Is there a patch for the EDK II PXE flaw?

A fix is merged into the source code, but no stable EDK II release includes it and the advisory lists no patched version. Operators must wait for firmware vendors to ship updates.