CVE-2026-97631 is a buffer overflow in the PXE network-boot driver of EDK II, the open-source UEFI code that most PC and server firmware is built on. TianoCore rates it 9.5 (CVSS 4.0), Red Hat 8.8 (CVSS 3.1).
It only matters while a machine is booting from the network. An attacker who can send it a crafted ICMP error message during that window can crash it, and with knowledge of the exact firmware build may run code before Secure Boot and the OS.
Machines that boot from their own disk are not exposed. The ones to worry about are PXE-provisioned servers, thin clients and VMs set to network boot.
No stable EDK II release or OEM BIOS update with the fix is listed yet, and no exploitation has been reported. Disable network boot where you don't use it, isolate it where you do, and watch your hardware vendor's BIOS advisories.
Despite the headlines, most laptops and desktops are not at risk from CVE-2026-97631: the flaw sits in the code that runs only when a machine boots over the network (PXE), and the attacker needs a position on that network at that moment. The machines that matter are servers and fleets that PXE boot for provisioning or as a fallback, and VMs configured to boot from the network. For those, disable PXE where you don't need it, keep provisioning traffic on an isolated VLAN, and install your server or motherboard vendor's BIOS/UEFI update when it appears. Operating system patches do not fix firmware.
What the bug is
The vulnerable code is in EDK II's NetworkPkg/UefiPxeBcDxe, the driver that implements PXE network boot. When the machine receives an ICMP error during network boot (the kind a router sends when a packet can't be delivered), the handlers for IPv4 and IPv6 copy it into a fixed 504-byte field without enforcing that limit, and advance the write position incorrectly. A crafted, oversized ICMP error therefore writes attacker-controlled bytes past the buffer (CWE-120, CWE-131, CWE-787).
The reliable outcome is a crash: the machine hangs or resets during boot. Researchers quoted by Ars Technica say code execution is also possible, before Secure Boot checks the operating system, but an exploit has to be tuned to the specific board, firmware version and configuration, because it depends on knowing memory addresses. HD Moore of Dragos noted it "could be used to break disk encryption" on systems whose TPM releases keys during boot (The Next Web, citing Ars Technica).
The flaw is credited to Alex Matrosov and Dan Holmes-Mitra. Disclosure was planned for January 2027, but a public firmware code change in September referenced the CVE and contained the fix, so TianoCore published its advisory (GHSA-99cj-7hg9-mp4m) early, on 22 October 2026.
How exposed are you, honestly
Exposed: servers and appliances that boot from the network, whether every time (diskless, thin clients, VDI) or for provisioning and reinstallation, and machines with network boot ahead of the disk in the boot order. Also VMs using OVMF (EDK II firmware for KVM/QEMU) that are set to network boot.
Network position: the advisory's CVSS score assumes the packet can come "from any network distance", but Red Hat and SUSE rate it as adjacent network, and the researchers told Ars an attacker needs some control of the local network. In practice: an insider, or an attacker already inside your network, during a boot.
Not exposed in practice: PCs and laptops that boot from their own disk. Many consumer boards ship with network boot off; it's a 30-second check in the firmware setup.
Exploitation: none reported, and it is not in the CISA KEV catalog as of its 27 October update. A public "proof of concept" repository exists, but its own author describes it as a lab harness against QEMU/OVMF that never reaches the vulnerable code.
Patch status
EDK II: the fix was merged into the main branch on 15 October 2026 (pull request #13302). No stable release includes it yet; the latest tag, edk2-stable202608, predates it, and the advisory lists no patched version.
Microsoft Project Mu released fixed builds on 26 October.
Linux distributions: Red Hat (RHEL 8, 9, 10), Debian and SUSE list their edk2/ovmf packages as affected and not yet fixed. That matters for VM hosts, where the firmware comes from the distro package.
Physical servers and PCs: the fix reaches you only as a BIOS/UEFI update from your hardware vendor, built from AMI, Insyde, Phoenix or in-house firmware. Intel says it knows of no affected products in its supported commercial line; Arm says the flaw doesn't directly apply to its products. Several vendors had not answered press questions at the time of writing.
What to do this week
Find the machines that network boot. Check your provisioning system (MAAS, Foreman, Ironic, Windows Deployment Services, iPXE setups), DHCP options 66/67, and the boot order on servers. Don't forget VM templates with network boot enabled.
Turn network boot off where it isn't used. In the firmware setup the option is usually called "Network Stack", "PXE Boot", or "IPv4/IPv6 PXE Support". Turning off the UEFI network stack removes the vulnerable driver from the boot path. Put the local disk first in the boot order on everything else.
Isolate what must PXE boot. Keep provisioning on its own VLAN that user devices and general servers can't reach, and restrict who can be on it. This is network hygiene rather than a vendor workaround, but it shrinks who can send that packet.
Watch for the symptom. Machines that hang or reset during PXE boot, and unexpected ICMP error traffic aimed at booting hosts on the provisioning network, are worth investigating.
Track firmware updates by vendor. Make a list of server and motherboard models and check Dell, HPE, Lenovo, Supermicro or your board vendor for a BIOS update that mentions CVE-2026-97631. For VM hosts, update the edk2/ovmf package when your distribution ships it, then power-cycle the VMs so they load the new firmware.
Plan for hardware that will never be patched. End-of-life servers won't get a BIOS update; disable network boot on them or document the residual risk.
Firmware is the layer most patch processes skip. Our stack check tracks the exploited vulnerabilities in the products you run, and this one is a good prompt to add firmware versions to your asset inventory, which NIS2 article 21 and PCI DSS both expect you to have. If you need to show that review to an auditor, our NIS2 pre-assessment covers asset management and vulnerability handling.
Questions
Is my PC affected by CVE-2026-97631?
Only if it boots from the network. A PC or laptop that starts from its own disk never runs the vulnerable PXE code during a normal boot; you can make sure by turning off network boot or the UEFI network stack in the firmware setup.
Can CVE-2026-97631 be exploited over the internet?
Not in practice. The attacker has to get a crafted ICMP error to the machine while it is booting from the network, which in real environments means being on, or controlling, the local or provisioning network.
Is there a patch for CVE-2026-97631?
The fix is merged in EDK II and Microsoft Project Mu has fixed builds, but as of 29 October 2026 there is no stable EDK II release with it and distributions list their packages as unfixed. For physical machines, wait for and install your hardware vendor's BIOS/UEFI update.
Not sure which of your machines network boot?
We map how your servers and endpoints boot, switch off what isn't needed, isolate provisioning networks, and add firmware versions to the vulnerability process so the next one doesn't slip past.