UEFI PXE Boot Flaw CVE-2026-97631: Who Is Exposed and What to Do Now

A critical flaw in firmware code used across the server industry deserves urgent attention. But the most important question is not whether your server uses UEFI. It is whether vulnerable firmware enters a PXE network-boot path while an attacker can deliver malicious ICMP traffic. [2]

The Ars Technica report concerns CVE-2026-97631, a memory-corruption vulnerability in TianoCore EDK II’s PXE Base Code driver. TianoCore rates it Critical, CVSS v4.0 9.5. The vulnerable code can run before the operating system loads. [1][2]

Operational summary: inventory network-boot exposure, follow your hardware or cloud provider’s mitigation guidance, and obtain the appropriate firmware update. Do not assume an OS package update, Secure Boot or an ordinary host firewall closes a pre-OS attack path.

1. Who is actually exposed?

The official advisory describes an unauthenticated network attack while the machine is PXE-booting over IPv4 or IPv6. PXE is used to boot from the network, including provisioning and some rescue or recovery workflows. The attacker must be able to deliver ICMP error messages to the booting machine; the exposure window is the PXE boot itself. [2]

The CVE record identifies affected EDK II releases through edk2-stable202608. The advisory separately identifies the master snapshot as of September 14, 2026. Neither is a complete list of affected retail server models, OEM firmware versions or cloud products. Vendors can customize and backport this code. [2][4]

This is why “most servers use this code” is not equivalent to “every server can be compromised right now.” You need the vulnerable implementation, the relevant boot path and a reachable network path.

Red Hat’s product statement makes the distinction explicit for its virtualized environments: guests booting strictly from local storage, or operating normally after boot, are not exposed to this flaw through that runtime path. Virtual-machine firmware can be affected too; this is not exclusively a physical-server issue. [7]

Do not assume the attacker must share your LAN. TianoCore says the message can arrive from any network distance if delivery to the PXE client’s IP is possible. Actual routing and filtering still determine reachability. The advisory also distinguishes a boot-hang outcome from code execution, for which it describes an attacker who knows the target firmware build. [2]

2. Why the pre-boot location matters

The bug is in the PXE driver’s handling of ICMP errors. Incorrect bounds and offset calculations allow attacker-controlled bytes to overwrite memory. The fix addresses both IPv4 and IPv6 handling. [2][5]

Successful code execution occurs in the DXE firmware execution environment, before the OS and before Secure Boot or measured boot have verified or measured OS components. Secure Boot being enabled is therefore not proof that this path is safe. This does not mean all Secure Boot or TPM functionality is universally broken. [2]

Ars reports that the initial payload is not itself persistent across boots, while warning that such execution could provide an opening for additional persistent payloads. A one-time execution opportunity is serious, but it is not evidence that every affected machine already contains a permanent bootkit. [1]

This article is a review of public advisories, upstream merge metadata and provider guidance. I have not scanned your servers, tested an exploit, changed boot settings or verified any individual machine as vulnerable or safe. The sources reviewed do not establish that a particular reader’s server has been exploited.

3. There is an upstream fix—but that is not your installed firmware

Status checked November 1, 2026. There is a material mismatch worth explaining:

• The TianoCore advisory’s “Patched versions” field still says “Not patched currently.” [2]
• Its linked PR #13302 was merged on October 15, 2026. GitHub’s API confirms merged: true, at 2026-10-15T00:09:15Z, with merge commit fa789071ff0b29f1e568bfe153ef7f3d76bd60e4. The change corrects bounds checks and offsets. [5][8]
• Debian’s tracker links upstream fix commits while still listing the affected edk2 packages shown on its page as vulnerable or unfixed at review time. That tracker describes Debian packages, not every OEM’s delivery status. [6]

The defensible conclusion is a source-level fix exists and was merged; availability of an installed fix must be verified for your actual firmware or guest-firmware package. Do not simply repeat “no fix exists,” and do not assume a merged PR means every supplier has delivered an update.

Ask the server manufacturer or cloud provider for the exact model/build, the advisory covering this CVE, the fixed version and the installation or rollout procedure. Follow the signed, supported update route. A generic EDK II source build is not a firmware image you should flash onto an arbitrary production server.

For virtualized environments, distinguish an update to the guest-firmware package from a change actually taking effect in a VM. Follow the platform’s documented activation procedure rather than assuming a guest OS reboot or package download is sufficient.

4. What administrators should do now

A. Inventory the boot path, not just the operating system

Record the physical model or VM platform, firmware build, PXE settings, boot order, fallback paths, and any rescue/provisioning workflow that invokes network boot. Include both IPv4 and IPv6.

UEFI mode alone does not prove that the vulnerable PXE component is present or reachable. Conversely, a machine that normally boots from disk may still invoke network boot through recovery or fallback settings. Check the actual configuration and provider documentation.

B. Reduce exposure without breaking recovery

Where the supported configuration permits it, disable unused network-boot paths or restrict their network exposure. Preserve a tested recovery plan and console access. Network controls must protect traffic before the OS boots; an in-guest firewall is not automatically active at that stage.

Do not copy a blanket “block all ICMP” rule into production. IPv4 and IPv6 have different operational dependencies, and indiscriminate filtering can break legitimate network functions. Use provider-supported, narrowly scoped controls and validate the consequences. A rule addressing ICMPv4 alone does not demonstrate protection of the ICMPv6 path described in the advisory. [2][3]

C. Plan necessary changes against current vendor guidance

Do not turn a provider-specific precaution into “never reboot any server.” Weigh the actual boot path, recovery requirement and other security needs. If a necessary reboot, reinstall or rescue action enters PXE, coordinate the documented mitigation before performing it.

Track the appropriate firmware or guest-firmware release, apply it through the supported procedure, and read back the resulting build/version. Keep evidence of both the update and any remaining exposure restrictions.

5. Hetzner customers: read the precise scope

Hetzner’s incident notice, including its October 30 updates, provides concrete operational guidance: [3]

• It identifies Dedicated Servers and Cloud VMs using UEFI.
• It says running systems are not directly at risk through this flaw. For Dedicated Servers, its stated risk window is a reboot; for Cloud VMs, it specifically identifies booting into the Rescue System.
• It recommends avoiding those boot processes where possible until a solution is available.
• As an additional temporary measure during reboots, it describes blocking incoming ICMP using the Hetzner Firewall, and instructs Dedicated Server customers to enable “Allow Hetzner Services” when creating those rules.
• Hetzner also describes implementing network filters for fragmented ICMPv4 and certain oversized ICMPv4 errors. Its update explicitly says the previous protection recommendations still apply.

These are Hetzner’s environment-specific instructions, not proof that every provider uses the same boot architecture or that a normal reboot of every cloud VM is exposed. Its IPv4 filtering announcement is not a blanket firmware patch or an independently verified guarantee for both protocol families.

Check the live notice before any planned reboot or rescue operation; provider mitigations and delivery status can change. I have not changed any server’s firewall or boot configuration for this article.

Bottom line

Treat this as a serious pre-OS network-boot vulnerability—not a reason to assume every running server is already compromised.

The next useful action is a small, specific checklist:

1. Does this machine enter vulnerable PXE firmware, including rescue or fallback?
2. Can untrusted ICMP traffic reach it during that boot path?
3. What supported mitigation and fixed firmware does its actual supplier provide?
4. Has that update been installed and activated, rather than merely announced upstream?

Those answers are more useful than either panic or reassurance based solely on a headline.

Sources

[1] https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth — Dan Goodin, Ars Technica: reported impact and limits [2] https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m — TianoCore official advisory: PXE prerequisites and pre-OS impact [3] https://status.hetzner.com/incident/54493dac-b3a2-44f0-8d8b-6de8b25d8f17 — Hetzner official operational guidance, updated October 30 [4] https://cveawg.mitre.org/api/cve/CVE-2026-97631 — AMI CNA CVE record: affected release range and CVSS v4 [5] https://github.com/tianocore/edk2/pull/13302 — Upstream fix PR: merged October 15, 2026 [6] https://security-tracker.debian.org/tracker/CVE-2026-97631 — Debian tracker: source fix versus shipped package status [7] https://access.redhat.com/security/cve/cve-2026-97631 — Red Hat product-specific statement: guest firmware exposure [8] https://api.github.com/repos/tianocore/edk2/pulls/13302 — GitHub merge metadata independently read back