On 22 October 2026, the TianoCore project published an advisory about CVE-2026-97631, a critical flaw in the PXE network boot driver of the EDK II UEFI. A crafted ICMP packet is enough to cause a buffer overflow and, in some cases, run code before Secure Boot verifies anything. It got less coverage than the PHP flaw of the same week, but it directly concerns workstations and servers that boot over the network.
What is established
- Component: the
NetworkPkg/UefiPxeBcDxedriver of EDK II, the UEFI code base used by several firmware vendors (AMI, Insyde, Phoenix). - Cause: the driver copies each ICMP error message into a 504-byte field, and the bounds check is wrong, in IPv4 and IPv6 alike.
- Severity: CVSS 4.0 score of 9.5 out of 10 according to IT-Connect. No authentication is required.
- Impact: denial of service (boot hangs), or code execution in the DXE phase with the highest privileges, for an attacker who knows the exact firmware version.
- Fix: merged into EDK II’s main branch on 15 October 2026. The advisory does not yet name a fixed version: firmware vendors, then hardware makers, must publish BIOS/UEFI updates.
- Virtual machines: for OVMF firmware, NixOS has merged the fix and Red Hat says it is working on one.
The attack window is narrow
The attack only plays out during PXE boot. A machine that boots from its local disk does not use this driver. The real risk therefore concerns:
- fleets deployed through PXE (Windows Deployment Services, MDT, deployment servers, clusters that boot over the network);
- machines whose boot order puts the network before the disk, or as a fallback;
- an attacker who must, in practice, be able to send traffic to the machine while it boots.
What to do
-
Review the boot order. If PXE comes before the disk, or as a fallback, the machine is exposed at every restart. Disable it in the BIOS/UEFI when you don’t use it (see the BIOS/UEFI cheatsheet for access keys by manufacturer).
-
Protect BIOS/UEFI access with a password, so the setting can’t be undone.
-
Isolate the deployment network. PXE installs belong on a dedicated VLAN, not on the users’ network.
-
Follow vendor advisories and apply firmware updates as soon as they are released. To see the current version on Windows:
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate -
For virtual machines, watch for an updated OVMF package from your hypervisor or distribution.
Takeaways
- Firmware is a layer that gets forgotten in patch inventories, even though it runs before everything else.
- The fix has been in the source code since 15 October, but you will have to wait for vendor updates: until then, reducing exposure (PXE disabled, isolated network) is the only protection.
- The flaw is limited to the PXE phase, which makes the workaround simple for most small fleets.
