EDK II UEFI Firmware: Pre-Boot RCE in PXE Network Boot (CVE-2026-97631)

A critical vulnerability, CVE-2026-97631, has been disclosed in the PXE network boot driver of EDK II. EDK II is the open source UEFI firmware that many vendor BIOSes are built on. It is also the source of OVMF, the UEFI firmware used by virtual machines on QEMU/KVM and Proxmox.

While a machine is PXE-booting, an unauthenticated attacker can send it a single oversized ICMP error message and overwrite firmware memory. With the right knowledge of the firmware build, that becomes code execution before the operating system starts, and before Secure Boot or measured boot have verified or measured any part of the OS.

The fix is merged upstream but is not in a tagged EDK II release, and Debian's edk2 packages are still listed as vulnerable. Until updates arrive, the main defence is making sure your machines don't network boot when they don't need to.

Key Takeaways

• CVE-2026-97631 is rated CVSS v4.0 9.5 (Critical). It affects the PXE driver in EDK II, the code behind OVMF and many vendor UEFI firmwares.
• It only matters while a machine is PXE-booting over IPv4 or IPv6. Booting from disk is not affected.
• The attacker only has to get ICMP error packets to the machine's IP, from any network distance. Without inside knowledge this hangs the boot. With the exact firmware build known, one crafted packet can run code.
• The fix was merged on 15 October 2026, but the latest EDK II release (edk2-stable202608) predates it, and Debian packages are unfixed.
• Remove network boot from the boot order wherever you don't use it, and keep PXE on an isolated provisioning network.

What is CVE-2026-97631?

CVE-2026-97631 is a buffer overflow in NetworkPkg/UefiPxeBcDxe, the PXE Base Code driver in EDK II. The bug is in the two functions that handle incoming ICMP error messages: PxeBcIcmpErrorDpcHandle for IPv4 and PxeBcIcmp6ErrorDpcHandle for IPv6.

During a PXE boot, the driver keeps a receive request open for ICMP error messages. It copies each one into Mode.IcmpError, a fixed 504-byte field. According to the EDK II advisory, the copy loop gets its bounds wrong in two ways:

• It does not stop at 504 bytes when a message is longer.
• It moves the destination pointer forward by the total length copied so far, instead of by the length of the piece it just copied.

Combined, these let an oversized message write attacker-controlled bytes past the end of the field. According to the advisory, "nothing earlier on the receive path restricts the message length".

The advisory was published on 22 October 2026. The bug was found by Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google), who also supplied the recommended fix.

What can an attacker do with it?

The advisory describes two outcomes:

1. Boot hang. The overflow corrupts the driver's private data, and the next ICMP error triggers a CPU exception in the DXE core. The machine stops booting. This works without knowing anything about the target.
2. Code execution in firmware. An attacker who knows the exact firmware build can put a fake event structure in the same packet. The firmware's own event dispatcher then runs the attacker's bytes in the DXE phase, at ring 0.

Secure Boot and measured boot work by checking code before it is loaded: the bootloader, then the kernel. This attack loads nothing. It takes over firmware code that is already trusted and running, before any OS component has been verified or measured. The operating system that boots afterwards has no record of it.

The CVSS v4.0 vector is AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The AT:P part ("attack requirements present") reflects the main condition: the target has to be PXE-booting when the packet arrives.

Who is affected?

You are exposed if a machine running EDK II-based firmware PXE-boots on a network an attacker can reach. The attacker needs to get one unicast ICMP or ICMPv6 error message to the machine's IP during the boot. The window lasts as long as the PXE boot does.

That includes:

• Virtual machines using OVMF (UEFI) on QEMU/KVM, libvirt or Proxmox, where network boot is in the boot order. This is easy to miss: a VM with a disk first and network second will fall through to PXE whenever the disk fails to boot, for example after a broken bootloader update.
• Physical servers whose vendor UEFI firmware includes the affected EDK II network code and has PXE enabled. Whether a given BIOS is affected depends on the vendor, so check with yours.
• Provisioning setups that PXE-boot machines on a network shared with other tenants or untrusted hosts.

Machines that boot from local disk and never reach the network boot stage are not affected. VMs using legacy BIOS (SeaBIOS) instead of OVMF don't run this driver.

This is not the first serious bug in this part of EDK II. In January 2024, Quarkslab disclosed PixieFail, nine vulnerabilities in the same NetworkPkg network stack used for PXE boot (Quarkslab). The pre-boot network stack runs for only a few seconds per boot, which makes it easy to forget about.

Is there a patch?

The fix exists but has not reached most people yet:

• Upstream: the fix was merged into EDK II on 15 October 2026 in pull request #13302, together with tests for the ICMP fragment copy. The latest tagged release, edk2-stable202608, came out before that, and the advisory still lists the patched version as "Not patched currently".
• Debian: the security tracker lists edk2 as vulnerable in bookworm, trixie, forky and sid, with no fixed version yet. For trixie it is marked no-dsa ("minor issue"), which means the fix is expected through a regular point release instead of a separate security advisory.
• Proxmox: Proxmox ships its own build of the firmware in the pve-edk2-firmware package. Watch their updates for a version that includes the fix.
• Physical servers: you'll need a BIOS/UEFI update from your hardware vendor. Expect that to take longer than the distribution packages.

What should you do now?

1. Remove network boot where you don't use it

A machine that never network boots is not exposed.

On Proxmox, check each VM's boot order:

qm config <vmid> | grep ^boot

If you see net0 (or another network device) in order=, set the order to disk only, for example:

qm set <vmid> --boot order=scsi0

With libvirt, look for <boot dev='network'/> in the <os> section, or a <boot order='...'/> element on an <interface>:

virsh dumpxml <vm> | grep -n "boot"

Remove those entries with virsh edit <vm>.

On physical servers, disable PXE in the BIOS setup. The options are often called "Network Stack", "IPv4 PXE Support" and "IPv6 PXE Support", but the names differ per vendor.

After making the change, watch the VM or server console during a boot. If you still see "Start PXE over IPv4" or "Start PXE over IPv6", network boot is still active.

2. Keep PXE on an isolated network

If you rely on PXE for provisioning, only do it on a dedicated network that other tenants, customers and the internet cannot send traffic into. The attack only needs one ICMP error packet to reach the booting machine, so filter ICMP and ICMPv6 error messages coming into that network from anywhere else.

3. Update firmware, then fully restart your VMs

When a fixed ovmf, edk2 or pve-edk2-firmware package is released, install it and then shut the VM down completely and start it again. A reboot from inside the guest keeps the same QEMU process running with the old firmware still loaded. On Proxmox, use Shutdown followed by Start. It's the same lesson as with PHP2Shell: installing the package is only half the job until the running process is restarted.

For physical servers, apply the vendor's BIOS update as soon as it is available.

Frequently Asked Questions

Is my server affected if it boots from disk?

No. The bug is in the PXE driver and only triggers while the machine is network booting. A machine that boots normally from its disk is not exposed. Check that network boot is not a fallback, though: if the disk fails to boot, many VMs and servers move on to PXE automatically.

Does Secure Boot protect against this?

No. The attacker's code runs inside the firmware during the DXE phase, before Secure Boot verifies the bootloader and before measured boot measures any OS component. Both features check what gets loaded next. They don't detect firmware that has already been taken over.

Can someone on the internet exploit this?

Only if they can get an ICMP error packet to the machine's IP while it is PXE-booting. The advisory says this works "from any network distance", so a routable address is enough. PXE on an isolated provisioning network is much harder to reach.

Is there a fixed EDK II release?

Not yet. The fix is merged upstream (pull request #13302), but no tagged EDK II release includes it, and distribution packages such as Debian's are still vulnerable. Use the boot-order and network isolation steps above until updates are available.

Sources: EDK II advisory GHSA-99cj-7hg9-mp4m · EDK II pull request #13302 · Debian security tracker: CVE-2026-97631 · Quarkslab: PixieFail