Critical EDK II PXE flaw lets network attackers run code before the OS boots

In brief

Developing. Last updated 29 October 2026, 12:11 Dubai time (UTC+4). Patch status checked 29 October 2026.

A critical flaw in the network-boot (PXE) driver of TianoCore EDK II, the open-source code behind much UEFI firmware, can let an unauthenticated attacker run code while a machine is PXE-booting. According to the project's GitHub advisory, this happens "before Secure Boot or measured boot has verified or measured any OS component". It is tracked as CVE-2026-97631.

What the flaw is

The advisory says the PXE Base Code driver mishandles oversized ICMP error messages in both its IPv4 and IPv6 handlers, writing attacker-controlled bytes past a fixed buffer. No login is needed. The attacker "needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance", and only while the machine is PXE-booting.

The advisory lists two outcomes: a boot hang, or, for an attacker who knows the target firmware build, code execution in the pre-boot DXE phase at ring 0.

Severity: GitHub's advisory scores it 9.5 under CVSS v4. Red Hat scores it 8.8 (High) under CVSS v3.1, but rates it Critical on its own severity scale. Its CVSS score is a draft that treats the attacker as adjacent-network (AV:A).

Credit: the advisory thanks "Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) for finding this issue and providing the recommended fix."

Who is exposed

EDK II at edk2-stable202608 or earlier, and master before the 15 October fix (commit fa78907, from pull request #13302). The advisory itself still lists the affected version as "EDK II master as of 2026-09-14" and shows "Not patched currently"; its patched field has not been updated.

Downstream, as of 29 October:

• Debian: its security tracker lists the edk2 source package as vulnerable in bookworm, trixie, forky and sid, with no fixed version; the oss-security post notes this means OVMF is vulnerable.
• Red Hat: edk2 is listed as affected in RHEL 8, 9 and 10, and in OpenShift 4's RHCOS images.

Ars Technica said it affects "most servers on planet Earth" because firmware vendors build on EDK II. Exposure exists only while a machine is PXE-booting; systems that boot only from local disks are not exposed through this path.

What to do now

• Apply firmware updates from your server, board or cloud vendor when they ship; ask them whether your firmware includes the fix.
• Until then, disable PXE boot where you do not need it.
• Where you do, keep PXE on trusted, segregated provisioning networks.
• Update OVMF/edk2 packages on virtualisation hosts once your distribution ships fixes.

Why it matters

This section is ByteNib analysis. The upstream fix is public, but each firmware vendor still has to ship it, so many fleets may stay exposed for months. Turning off PXE is the quickest way to reduce risk.

Sources and scope

• TianoCore EDK II advisory GHSA-99cj-7hg9-mp4m
• EDK II fix: pull request #13302 (merged 15 October 2026)
• oss-security: CVE-2026-97631, 28 October 2026
• Red Hat: CVE-2026-97631
• Debian security tracker: CVE-2026-97631
• Ars Technica: Code-execution flaw in UEFI firmware affects most servers on planet Earth (27 October 2026)

Ars Technica is used for context only. Exploit details are deliberately omitted. The "Why it matters" section is ByteNib editorial analysis. This article was researched and drafted with AI assistance and edited under ByteNib's editorial standards.

Drafted with AI assistance and reviewed by the editor before publication.

Continue exploring: Cybersecurity analysis, the related implementation tutorial, and the structured learning path.