Vulnerabilities

CVE-2026-97631 is a buffer overflow in the network boot code of TianoCore EDK II, the open-source base that AMI, Insyde and Phoenix build their UEFI firmware on. A server that boots over the network with PXE (Preboot Execution Environment) can be hung, or made to run attacker code, by a single oversized ICMP error message that arrives while it boots. The code runs in firmware, before Secure Boot or measured boot has checked anything. TianoCore rates it 9.5 under CVSS 4.0. The bug is about 16 years old.

The disclosure went wrong. Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google found the flaw and planned to go public in January 2027, but a fix posted publicly on September 28 named the CVE, a revised fix (pull request 13302) was merged on October 15, and TianoCore published its advisory on October 22. The source code is fixed; most server firmware is not yet. If your servers PXE boot, or fall back to PXE when the disk fails, you are inside the window on every reboot.

How it works

During a PXE boot the UEFI firmware brings up its own small network stack, gets an address over DHCP and downloads a boot loader over TFTP or HTTP. The PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive open for ICMP error messages, such as "destination unreachable", so it can report why a download failed. Each one is copied into Mode.IcmpError, a fixed 504-byte field in the driver's private data.

The copy loops in PxeBcIcmpErrorDpcHandle (IPv4) and PxeBcIcmp6ErrorDpcHandle (IPv6) get the bounds wrong in two ways. They copy messages longer than 504 bytes anyway, and they advance the destination pointer by the running total instead of each fragment's length. Nothing earlier in the receive path caps the size, so the attacker's bytes land in whatever memory follows the field.

TianoCore describes two outcomes. Without knowing anything about the target, corrupted driver data makes the next ICMP error raise a CPU exception and the boot hangs. An attacker who knows the exact firmware build can plant a fake event structure in the same packet, so the firmware's own CoreSignalEvent() jumps to attacker-supplied code. That happens in the DXE (Driver Execution Environment) phase at ring 0, the highest CPU privilege, before any operating system security control exists. Secure Boot and the TPM (Trusted Platform Module) measurements do not help here, because the takeover happens before either checks anything. The payload itself does not survive a reboot, but code at that stage can install something that does.

Reach is where the sources disagree. TianoCore's vector is network attack from "any network distance", needing only a unicast ICMP error to the booting machine's IP. Red Hat and SUSE score it 8.8 under CVSS 3.1 with an adjacent-network vector. In practice the attacker has to know when a machine is booting and get packets to it in that short window, which points at insiders and intruders already on the provisioning network.

What attackers are doing

No exploitation has been reported. The flaw was not in CISA's Known Exploited Vulnerabilities catalog as of October 27, and neither TianoCore, Red Hat nor SUSE reports attacks. The risk is that the public patch shows exactly which loop to abuse while firmware updates move slowly. A reliable exploit has to be tuned per firmware build, but the boot hang needs no tuning at all.

Who is affected

Any firmware built from EDK II with the PXE driver and network boot turned on. Because AMI, Insyde and Phoenix all build on EDK II, that reaches most mainstream server brands, though each vendor has to confirm which models ship the driver. The upstream advisory names EDK II master as of September 14, and edk2-stable202608, the stable release from August 21, is affected. No stable EDK II release contains the fix yet, and the advisory still lists no patched version. Microsoft's Project Mu shipped builds with the fix on October 26. Intel says it knows of no affected supported commercial products, and Arm says the flaw does not apply directly to its products, though Intel notes that device makers can add the vulnerable code themselves.

Machines that only boot from a local disk never load the driver. Virtual machines are affected through OVMF, EDK II's firmware for QEMU and KVM guests, when they network boot. As of October 28, Red Hat listed edk2 in RHEL 8, 9 and 10 as affected with no fix, SUSE's ovmf fix was pending, Debian was unfixed in bookworm, trixie, forky and sid, and Fedora 43 to 45 had fixed builds in testing.

What to do

1. List every physical server and hypervisor host whose boot order contains a network entry, including PXE as a fallback after the disk. Out-of-band management can pull this for a whole fleet: the Redfish Boot.BootOrder property under /redfish/v1/Systems/<id> shows it per machine.
2. Where PXE is not needed, turn it off in firmware setup. On AMI Aptio based boards this is usually under Network Stack Configuration, with separate IPv4 PXE Support and IPv6 PXE Support switches. Turn off both, since both handlers are vulnerable.
3. Where PXE is needed, keep the provisioning network on its own VLAN, reachable only from your DHCP, TFTP and deployment servers. Block ICMP error messages (ICMPv4 type 3, 11 and 12, ICMPv6 types 1 to 4) into that VLAN from anything other than its own gateway.
4. Ask your server vendor for a BIOS update or a statement that your models are not affected. Supermicro has published fixed BIOS versions for many boards, for example 2.7 for most X12 Whitley boards and X12 Tatlow, 3.2 for most X13 Eagle Stream boards, 5.3a for X13 Alder Lake and 2.0 for most X14 Birch Stream boards. Several older X11 families are listed as "by request". Check the advisory for your exact model.
5. For KVM and QEMU hosts, update the edk2 or ovmf package once your distribution ships it, then cold start each guest (a full power off, not a guest reboot) so it loads the new firmware.

There are no published indicators of compromise. A server that hangs in PXE boot for no clear reason is worth investigating. If you capture traffic on provisioning networks, look for ICMP errors sent to booting hosts from unexpected sources, especially IPv4 errors above 576 bytes, which RFC 1812 says routers should not send. A suspected pre-boot compromise is not cleared by reinstalling the OS. Reflash the firmware from the vendor image and only then rebuild.

The wider lesson

Network boot often survives in the boot order long after the server is built, as a fallback nobody remembers. That turns a flaw meant to need precise timing into one triggered by every planned reboot. Treat the boot order as configuration you check, the same way you check open ports.

Our hardening work covers firmware settings and boot order across server fleets, and our network penetration tests check who can reach provisioning and management networks. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: TianoCore advisory GHSA-99cj-7hg9-mp4m, Supermicro security advisory, The Next Web, Security Affairs, Rescana, IT-Connect, Thomas-Krenn, SecurityWeek.