UEFI Firmware Vulnerability CVE-2026-97631: The 16-Year-Old EDK II Network Boot Flaw

A newly disclosed flaw in EDK II, the open-source code that most PC, server and virtual machine firmware is built on, lets an attacker on the network crash or take over a machine while it is network booting, before Windows or Linux has even started. If any of your servers, virtual machines or lab machines boot over the network (PXE), this deserves an hour of attention this week, because nothing running inside the operating system can see or stop it.

What is the EDK II UEFI firmware vulnerability?

CVE-2026-97631 is a buffer overflow in the PXE network boot driver of EDK II, also known as TianoCore, the reference UEFI firmware that hardware and virtualization vendors build on. TianoCore's own advisory, published October 22, 2026, is titled "Pre-boot RCE in EDK II PXE driver." It rates the flaw Critical, with a CVSS v4 score of 9.5.

The bug sits in the NetworkPkg/UefiPxeBcDxe driver, in the code that handles ICMP error messages (the "destination unreachable" style replies that routers and hosts send back) for both IPv4 and IPv6. The driver stores these messages in a fixed 504-byte field. According to the advisory, the copy loop gets its bounds wrong, so an oversized message is written past the end of that field, and nothing earlier on the receive path limits the message length.

The advisory credits Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) with finding the issue and supplying the recommended fix.

How the network boot attack works

The advisory says an unauthenticated attacker who can deliver ICMP error messages to a machine during network boot can corrupt firmware memory. It describes two outcomes:

• A boot hang. The memory corruption is deterministic and crashes the firmware on the next ICMP error, so the machine never finishes booting.
• Code execution. An attacker who knows the exact firmware build can plant a fake event in the same packet, so the firmware runs the attacker's bytes during the DXE phase, the stage where firmware drivers load.

Code that runs at that stage runs before the boot loader and the operating system. Antivirus, EDR agents, OS logging and firewall rules are not running yet, so they cannot help.

What is confirmed and what is not

Confirmed from primary sources:

• The CVE number, severity and affected driver, from TianoCore's advisory.
• A fix, pull request 13302, was merged into EDK II's main branch on October 15, 2026. It adds bounds checks, corrects the offset math and truncates oversized messages.
• The newest EDK II stable release, edk2-stable202608, came out on August 21, 2026, before the fix. At the time of writing there is no stable release that includes it, and the advisory still lists the patched version as "Not patched currently."
• Red Hat scores it 8.8 under CVSS 3.1 with an "adjacent network" attack vector, and says the exposure is during PXE boot of virtualized guests in Red Hat Enterprise Linux and OpenShift.
• Debian's security tracker lists its edk2 packages in bookworm, trixie and sid as vulnerable, with no fixed version yet.
• The code is old. The commit that added NetworkPkg, including the PXE driver, came from the UDK2010 release, which is where the "16-year-old" label comes from.

Not confirmed or not known:

• Which specific server, motherboard and laptop models are affected. Commercial firmware vendors build on EDK II, but each one decides what code ships, and we did not find vendor-by-vendor lists.
• Whether the fix is complete. After the merge, a commenter on the pull request said a network flood could still cause a denial of service. That is a claim, not a confirmed finding.
• Exploitation in the wild. The advisory does not mention any, and we found no credible report of it.

The disclosure was also messier than usual. An EDK II maintainer wrote in the pull request that the embargo was broken by mistake, which is why the fix was worked on in public before vendors had updates ready. That gap is the real risk window.

Why two different scores?

TianoCore's 9.5 treats this as a network attack. Red Hat's 8.8 assumes the attacker must be on the adjacent network. In practice, an attacker needs to reach the machine with crafted packets at the moment it network boots, which usually means being on the same network segment or in the traffic path. That is a real limit, but a single compromised device on a flat office or server network meets it.

Who is at risk from this UEFI flaw

You are most exposed if:

• Servers are provisioned or reimaged with PXE boot, which is common in data centers, labs, schools, render farms and thin-client deployments.
• Virtual machines use UEFI (OVMF) firmware with network boot enabled, on KVM, QEMU, Proxmox, OpenShift or similar platforms.
• Network boot sits first in the boot order "just in case," so every reboot tries the network before the disk.
• Your provisioning network is shared with staff devices, guest Wi-Fi or anything else you do not fully control.

You are much less exposed if machines boot only from local disk and network boot is disabled in firmware. Most office laptops and desktops fall into this group.

What to do this week

If you rely on a cloud provider, the virtual firmware is the provider's job. Check their security bulletins rather than trying to patch it yourself.

Why this matters for a business network

Firmware is the layer most businesses never patch. Operating system updates arrive automatically; BIOS and UEFI updates usually wait until something breaks. This flaw shows why that habit is risky: the fix exists in the upstream code, but it will not reach your servers until your hardware or hypervisor vendor ships it and someone installs it. We covered that gap in Updated Is Not the Same as Patched and Who Is Patching the Software That Runs Your Business?.

It is also a reminder that network design is a security control. If an attacker has to be on the same segment to hit a booting machine, a separate provisioning network turns a critical flaw into a contained one. If you run your own servers, our self-hosting infrastructure page explains how we approach that.

UEFI firmware vulnerability questions people are asking

Is my laptop or desktop affected?

Probably not in practice. The vulnerable code runs only during network boot. A PC that boots from its internal drive with network boot disabled does not run it.

Is there a patch for CVE-2026-97631?

The upstream fix was merged on October 15, 2026, but no EDK II stable release includes it yet. You need a firmware or OVMF update from your hardware, hypervisor or Linux vendor.

Does Secure Boot stop this attack?

No. Secure Boot checks the signatures of boot loaders and drivers loaded from outside the firmware. This bug is inside the firmware's own trusted network code, and it triggers before those checks matter.

Can it be exploited over the internet?

The attacker must deliver ICMP error messages to the machine while it is network booting. That usually means being on the same network or in the traffic path. Red Hat rates the attack vector as adjacent network.

Is the EDK II flaw being exploited?

There is no confirmed exploitation. The advisory does not mention any, and we found no credible report.

Will a Windows or Linux update fix it?

Not by itself. The bug is in firmware. For virtual machines, the fix comes through the host's edk2 or OVMF package; for physical servers, through a BIOS or UEFI update.

The bigger lesson

The most dangerous code is often the code nobody remembers is running. A network boot option left on for convenience, in firmware nobody updates, sat exposed for 16 years. Knowing what your machines actually do when they power on is part of securing them.

Want a second set of eyes on your servers and firmware? See our security hardening services or request a tech quote.

Get security alerts like this by email, plus our free security checklist, at our security alerts page.

Sources: TianoCore EDK II advisory GHSA-99cj-7hg9-mp4m; EDK II fix pull request 13302; Red Hat CVE-2026-97631; Debian security tracker CVE-2026-97631; EDK II releases.