EDK II UEFI PXE Flaw CVE-2026-97631: Critical Pre-Boot Code Execution Risk, Patch Not ...

On 22 October 2026, TianoCore, the project that maintains EDK II, published an advisory for CVE-2026-97631, a buffer overflow in the network boot (PXE) driver of EDK II ( TianoCore GHSA-99cj-7hg9-mp4m ). EDK II is the open-source reference code for UEFI, the firmware that starts a computer before its operating system. TianoCore rates the flaw Critical, with a CVSS 4.0 score of 9.5. It says an unauthenticated attacker who can send ICMP error messages to a machine while it is booting from the network can hang the boot, and, with knowledge of the exact firmware build, run code "before Secure Boot or measured boot has verified or measured any OS component".

For most systems there is no patch to install yet. TianoCore merged a code fix into its development branch on 15 October, but no stable EDK II release contains it, and the advisory still lists the patched version as "Not patched currently" ( TianoCore ; EDK II releases ). Red Hat, SUSE and Debian list their EDK II packages as affected with no fix yet. Fedora has built fixed packages, but for Fedora 43, 44 and 45 they are still in testing, not released as stable updates ( Fedora ). As of 28 October 2026 the flaw is not in CISA's Known Exploited Vulnerabilities catalog, and we found no official report of exploitation or of a public exploit.

The exposure is narrow but sits in a sensitive place. Machines are only exposed while they boot over the network, which is how many data centres, hosting providers and managed service providers build and recover servers. This is a good moment to find out which of your suppliers do that, and when their firmware fixes will arrive.

Technical Information

What the flaw is. According to TianoCore, during a network boot the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps listening for ICMP error messages and copies each one into a fixed 504-byte field. The size checks in that copy are wrong in both the IPv4 and the IPv6 handler, so a longer message writes attacker-controlled bytes past the end of the field. TianoCore says nothing earlier on the receive path limits the message length ( TianoCore ). The CVE record lists the weaknesses as CWE-120 (classic buffer overflow), CWE-131 (incorrect buffer size calculation) and CWE-787 (out-of-bounds write) ( CVE record ).

What an attacker can do, per TianoCore. The advisory describes two outcomes:

Boot hang. An oversized ICMP error message corrupts the driver's data, and the one causes a CPU exception. The boot hangs, which TianoCore describes as denial of OS provisioning or recovery.

Code execution before the operating system. "An attacker who knows the target firmware build" can make the firmware run attacker-supplied bytes in the DXE phase of boot, in CPU ring 0 and "before any OS security control exists".

When a machine is exposed. TianoCore says the attack is unauthenticated and works only "while a machine is PXE-booting over IPv4 or IPv6". The attacker has to deliver a unicast ICMP error message addressed to the booting machine's IP address, and "the exposure window is the duration of the PXE boot". Machines that are not network booting are outside that window. Reliable code execution also depends on knowing the exact firmware build; the boot hang does not.

How it is scored. The scores differ on how close the attacker must be:

Sources: TianoCore ; Red Hat ; SUSE . NVD lists the record as "Deferred" and shows only TianoCore's 9.5 score; it has not published its own assessment ( NVD ).

Exploitation status. Not in CISA KEV (catalog version 2026.10.27, checked 28 October 2026). TianoCore, Red Hat, SUSE and NVD do not report exploitation, and we found no official report of a public exploit. No national CERT advisory had been published when we checked.

How the fix became public. The fix was first proposed in a public pull request, #13200, opened on 28 September 2026 with the CVE number in its description ( PR #13200 ). A revised version, pull request #13302, replaced it on 14 October and was merged into EDK II's master branch on 15 October 2026 ( PR #13302 ). On 27 October, the TianoCore member who published the advisory wrote on #13302 that, for this advisory, the embargo "was violated due to a mistake, resulting in the PR being created in the open". In practice, the code change has been publicly visible since late September, more than three weeks before the advisory. That is a reason to plan the update, not evidence of attacks.

21 August 2026: EDK II releases edk2-stable202608, its latest stable version, which is affected [EDK II releases].

28 September 2026: The fix is first proposed in public pull request #13200, which names the CVE [PR #13200].

14 October 2026: Revised pull request #13302 is opened in public and replaces #13200 [PR #13302].

15 October 2026, 00:09: The fix is merged into the EDK II master branch [PR #13302].

22 October 2026, 14:34: TianoCore publishes advisory GHSA-99cj-7hg9-mp4m, rated Critical (CVSS 4.0 9.5) [TianoCore].

22 October 2026, 16:32: The CVE record is published; Red Hat's CVE page gives the same public date and time [CVE record; Red Hat].

22 October 2026, 17:17: NVD publishes the record [NVD].

26 October 2026: Fedora adds the fix to its edk2 packages; updates for Fedora 43, 44 and 45 enter testing [Fedora].

27 October 2026: TianoCore says on the pull request that the embargo was broken by mistake [PR #13302].

28 October 2026: No stable EDK II release with the fix; Fedora 43 to 45 updates still in testing; not in CISA KEV.

TianoCore credits Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) with finding the flaw and providing the recommended fix.

Affected Product Versions

Distribution statuses were checked on 28 October 2026 and are changing. The distribution packages are firmware for virtual machines (OVMF is the EDK II build for VMs). Physical servers get UEFI firmware from their hardware or BIOS vendor, not from EDK II directly. We found no firmware vendor advisory for this CVE at the time of writing, so we do not name any vendor's products as affected or unaffected. Ask your hardware and firmware suppliers directly.

Workaround and Mitigation

TianoCore lists no workaround. Until a firmware update built from the fix is available for your systems:

Find out where you network boot. List the physical servers and virtual machines that use PXE, including those that only fall back to it for provisioning or recovery.

Disable PXE where it is not used. The exposure window exists only during a PXE boot, so machines that never network boot do not need it enabled in firmware (Rescana guidance, based on TianoCore's description) .

Isolate provisioning networks. Keep PXE and provisioning segments separate, and limit who can send traffic to hosts while they boot (Rescana guidance) .

Filter inbound ICMP error messages to booting hosts at the edge of provisioning segments, where your network design allows it. This is a defensive step derived from the advisory's description, not a TianoCore-stated workaround (Rescana guidance) .

Track firmware and distribution updates. Watch your hardware or BIOS vendor for a UEFI update that includes the EDK II fix, and your Linux distribution for an updated edk2 or ovmf package for virtual machines. Apply them when available.

Keep Secure Boot and measured boot on. TianoCore's description means they do not stop this flaw, because the code runs before they act, but they still protect against other threats.

Indicators of Compromise

TianoCore, Red Hat, SUSE and CISA have not published indicators of compromise for CVE-2026-97631, and we have none to add. No source we checked maps this flaw to MITRE ATT&CK techniques, and we have not done so.

We will update this post when EDK II publishes a stable release that includes the fix, when the first firmware vendor or Linux distribution ships a fixed stable update, if TianoCore revises its advisory, if CISA adds CVE-2026-97631 to KEV or exploitation is reported, if NVD publishes its own score, or if a national CERT issues guidance.

TianoCore (EDK II maintainer and CNA): Advisory GHSA-99cj-7hg9-mp4m, "Pre-boot RCE in EDK II PXE driver" (22 October 2026): ; fix pull requests #13200 (opened 28 September 2026): and #13302 (merged 15 October 2026): ; EDK II releases:

NVD and CVE Program: ;

CISA: not in the KEV catalog as of catalog version 2026.10.27, checked 28 October 2026:

Red Hat and Fedora (Red Hat- ): Red Hat CVE-2026-97631: ; Bugzilla 2559129: ; Fedora edk2 updates:

SUSE:

Debian:

Why this matters for your vendors

The machines most likely to network boot are the ones you rarely see: servers at your hosting, colocation, cloud and managed service providers, which they build and recover over provisioning networks. Until firmware fixes ship, the useful question is not whether a supplier is patched, but whether it knows where it uses PXE and who can reach those machines while they boot.

Forward this to your TPRM owner: Three short questions for infrastructure suppliers (Rescana guidance) :

Do you PXE-boot servers or virtual machines (including VMs using OVMF firmware) for provisioning or recovery?

On which networks does that happen, and who can send traffic to those machines while they boot?

When will your firmware or BIOS vendor, or your Linux distribution, ship the EDK II fix for CVE-2026-97631, and when will you apply it?

Working with firmware and hosting suppliers on questions like these? We can help you track their answers alongside the rest of their security posture. Book a demo .