VULNpocalypse
HighVulnerabilityActive

TianoCore EDK II PXE driver pre-boot RCE (CVE-2026-97631): fixed on main, in no stable release yet

An EDK II PXE driver overflow can run code before the OS and Secure Boot. No stable fix yet: disable PXE where unused and isolate boot networks.

Published
Updated
Fixed in
Not in any stable EDK II release; fix merged to main on 15 October 2026 (PR 13302); Project Mu tagged builds on 26 October
Exploitation
No. No exploitation reported and not in CISA KEV as of 30 October 2026

Live scores

CVE-2026-97631
EPSS
0.006
low predicted chance of attack
VEDAS
0.512
some exploit evidence
On CISA KEV
Not listed
Detection rule
None yet

What happened

On 22 October 2026, TianoCore published GHSA-99cj-7hg9-mp4m for CVE-2026-97631, rated CVSS 4.0 9.5. It is in the PXE Base Code driver, NetworkPkg/UefiPxeBcDxe, which EDK II uses for network boot (TianoCore).

During a PXE boot, the driver keeps a receive request open for ICMP error messages and copies each one into a fixed 504-byte field, Mode.IcmpError. The bounds handling is wrong in both the IPv4 handler (PxeBcIcmpErrorDpcHandle) and the IPv6 handler (PxeBcIcmp6ErrorDpcHandle). Longer messages are still copied, and the write pointer advances by the running total, so attacker bytes land past the field (TianoCore).

An unauthenticated attacker who can deliver a unicast ICMP error to the machine’s IP during PXE boot can:

  • reliably hang the boot, or
  • if they know the exact firmware build, plant a counterfeit event in the same packet and run their own code in the DXE phase, before Secure Boot and measured boot have checked anything (TianoCore).

The flawed copy loop dates from a November 2010 commit. Red Hat and SUSE rate the bug as exploitable from an adjacent network, not from the internet (The Hacker News). The finders are Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) (CVE record).

It went public early. Coordinated disclosure was planned for January 2027. On 28 September, a public pull request to EDK II (#13200), signed off by an AMI engineer, named the flaw by CVE number and included the fix. TianoCore then published its advisory weeks early (The Hacker News).

Fix status. The fix, PR #13302, truncates oversized messages at 504 bytes. It was merged to the EDK II main branch on 15 October. No stable release includes it; the latest, edk2-stable202608, predates it, and the advisory still says “Not patched currently.” Microsoft’s Project Mu cut tagged builds with the fix on 26 October. Red Hat lists edk2 in RHEL 8, 9 and 10 as affected and not yet fixed; SUSE and Debian mark theirs the same way (The Hacker News). The CVE record lists all EDK II versions up to and including edk2-stable202608 (CVE record).

Why this matters

Code that runs this early sits below the operating system, Secure Boot and EDR. It does not persist on its own, but it can install something that does. HD Moore noted the boot process may have access to the TPM, so short-term network access could be used against disk encryption (The Hacker News). EDK II is the base for most commercial UEFI firmware, including AMI, Insyde, Phoenix and Project Mu, so the fix has to travel through every firmware vendor before it reaches your hardware.

Am I affected?

You are exposed if a machine PXE boots using EDK II-derived UEFI firmware that does not yet have the fix. Machines that only boot from local disk are not reachable through this bug. Intel says its reference code does not include the affected functionality, though OEM boards could add it; Arm says it is not directly applicable to its portfolio. AMI, Insyde, Phoenix, AMD and Microsoft had not commented as of 28 October (The Hacker News).

Does this machine try to network boot? On a running Linux host with UEFI:

bash
efibootmgr -v | grep -iE 'pxe|ipv4|ipv6|mac\('

Boot entries that point at a MAC address or IPv4/IPv6 path are network boot options. Check whether one sits ahead of the local disk in BootOrder.

Virtual machines. Guests using OVMF or AAVMF firmware get it from the host’s edk2 package. Check its version and watch your distribution’s tracker:

bash
rpm -q edk2-ovmf        # RHEL, Fedora
dpkg -l ovmf            # Debian, Ubuntu

Firmware you build. If you build firmware from EDK II, check whether your tree contains PR #13302. Any tree based on edk2-stable202608 or earlier without it is affected.

What to do now

  1. Disable PXE boot in firmware setup on servers and VMs that do not need network boot. This removes the exposure entirely, since the bug is only reachable during PXE boot.
  2. Isolate PXE provisioning networks. Put PXE-booting machines on a dedicated VLAN that untrusted hosts cannot send ICMP into, and filter ICMP error messages towards PXE clients at the boundary.
  3. Track your firmware vendor. Ask your server OEM or BIOS vendor (AMI, Insyde, Phoenix) for a firmware update that includes the EDK II fix. Eclypsium’s Jesse Michael notes it is a plain code fix with no key or certificate revocation needed (The Hacker News).
  4. Update edk2 or OVMF packages on hypervisor hosts when Red Hat, SUSE, Debian or your cloud image vendor ships them, then restart guests so they load the new firmware.
  5. If you build firmware, cherry-pick PR #13302 now, or move to a Project Mu tag from 26 October or later.
  6. Watch boot networks. Unusual ICMP error traffic directed at machines while they PXE boot, or machines that hang during network boot, are the visible signs.

Sources