EDK II PXE Firmware Flaw CVE-2026-97631 Explained: 9.5 Pre-Boot Bug in Most Servers, No Stable Fix Yet
Illustrative image: server racks in a data centre — the kind of infrastructure whose firmware carries this flaw. Firmware is code, not a device, so no product photograph exists. (Image: Wikimedia Commons / NERSC, CC0)
TL;DR — EDK II PXE firmware flaw CVE-2026-97631 explained: a critical 9.5-rated bug in the open-source firmware underneath most servers lets an unauthenticated attacker run code before the operating system — and before Secure Boot — by sending a single oversized network packet while a machine boots over the network. The fix exists in source code, but no stable firmware release carries it yet.
📌 KEY HIGHLIGHTS
- The flaw: CVE-2026-97631, a buffer overflow in the PXE network-boot driver of TianoCore EDK II, rated 9.5 out of 10 (CVSS v4.0).
- The trigger: one oversized ICMP error message sent to a machine while it is PXE-booting — no login, no click, no malware needed.
- The prize: code running in the DXE phase at ring 0, before Secure Boot or measured boot has checked anything — with the TPM still in reach.
- The catch for attackers: the target must be network-booting at that moment, and the exploit must be tuned to its exact firmware build.
- The patch gap: fixed in EDK II master code since 15 October 2026, but no stable release yet — and no vendor firmware updates as of 28 October.
- No exploitation reported so far, and the flaw is not in CISA's Known Exploited Vulnerabilities catalogue as of 29 October.
EDK II PXE firmware flaw CVE-2026-97631 explained: what happened?
On 22 October 2026, the TianoCore project published security advisory GHSA-99cj-7hg9-mp4m, titled "Pre-boot RCE in EDK II PXE driver". EDK II is the open-source reference implementation of UEFI — the firmware that starts a machine before any operating system loads. It is not one vendor's code: AMI, Insyde and Phoenix, the independent BIOS vendors behind most server firmware, all build on it, and Microsoft's hardened Project Mu fork carried the same vulnerable component. That is why one bug in one driver reaches, in Ars Technica's phrase, most of the world's servers.
The flaw is 16 years old. It sat in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) — the part of firmware that lets a machine pull its boot image over the network instead of from a disk — through every fuzzing campaign that followed PixieFail, the 2024 batch of bugs in this same EDK II network stack. It was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, who had arranged a calm coordinated disclosure for January 2027. That plan fell apart when a public pull request from AMI in September named the CVE and contained the fix — so TianoCore published early, with patch code in the open and vendor firmware nowhere.
How one ICMP packet breaks the boot
PXE boot works like this: a machine with no disk image asks the network for one. While it waits, its firmware keeps a listener open for ICMP error messages — the network's "that didn't work" notes. The driver copies each message into a fixed 504-byte field. TianoCore's advisory says the copy loop gets its bounds wrong in both the IPv4 and IPv6 handlers: for a message longer than 504 bytes it keeps copying, and it advances the destination pointer by the cumulative rather than the per-fragment length. Attacker-controlled bytes land past the end of the buffer, and nothing earlier on the receive path caps the message size.
| Fact | Detail |
|---|---|
| CVE | CVE-2026-97631 — buffer overflow / out-of-bounds write in the EDK II PXE driver |
| Severity | 9.5 out of 10 (CVSS v4.0), critical |
| Component | NetworkPkg/UefiPxeBcDxe — the PXE Base Code driver |
| Trigger | A unicast ICMP error message addressed to the machine's IP, sent while it is PXE-booting over IPv4 or IPv6 |
| Minimum effect | Corrupted driver data and a CPU exception in the DXE core on the next ICMP error — the boot hangs |
| Maximum effect | With knowledge of the exact firmware build, attacker code dispatched in the DXE phase at ring 0, before Secure Boot or measured boot |
| Authentication needed | None — unauthenticated, pre-boot, over the network |
| Persistence | The payload itself does not persist across reboot — but one run is enough to plant something that does, such as a bootkit |
Illustrative image: a server room. The flaw lives in firmware code, not in any pictured hardware. (Image: Wikimedia Commons / Florian Hirzinger, CC BY-SA 3.0)
The realistic limits matter as much as the severity score. An attacker must reach the machine during its short PXE-boot window, and the exploit must be tuned to that model, firmware version and configuration — Eclypsium researcher Jesse Michael told Ars Technica that memory addresses differ per build, so this cannot be sprayed blindly at a fleet. Machines that boot only from a local disk — nearly every home and office PC — are not exposed. And the advisory's own wording cuts both ways: it says the packet can be delivered "from any network distance", but in practice the attacker must be able to reach the booting machine's network segment, which is why researchers describe this as a threat for insiders or intruders who already hold a local-network foothold. HD Moore, the creator of Metasploit and now Dragos' chief research officer, told Ars the sharpest consequence: the boot process still has access to sensitive components like the TPM at that stage, so breaking disk encryption is one realistic use.
Who has a fix — and who does not
The code fix is simple. Unlike BootHole or BlackLotus, there are no Secure Boot keys to revoke and no revocation lists to push — it is a plain code fix, merged into EDK II master on 15 October 2026 (pull request #13302). The hard part is everything downstream: thousands of OEM firmware trees, each needing a rebuild, validation and an owner willing to flash it. As of 28 October, the picture was:
| Vendor / project | Status (checked 28 October 2026) |
|---|---|
| TianoCore EDK II (upstream) | Fixed on master since 15 October; no stable release carries the fix; advisory still lists EDK II master as of 14 September as affected |
| Microsoft Project Mu | Fix backported in mu_basecore release v2026080000.0.5 (26 October) and an older release branch (28 October) |
| Red Hat (RHEL 8, 9, 10) | edk2 package listed as affected; no erratum listed |
| Debian (bookworm, trixie, forky) | edk2 package listed as affected; no fixed version |
| SUSE / openSUSE | ovmf packages listed as affected; fix pending |
| Intel | Says no commercial product under security support is known to be affected; does not include the affected code in its reference code |
| Arm | Says the bug is "not directly applicable" to its product line |
| AMD, AMI, Phoenix, Amazon | Had not answered Ars Technica's questions when its story ran |
Until vendor firmware arrives, the practical advice is the one Ars Technica gives: if a machine never network-boots, switch PXE and the UEFI network stack off in firmware setup — that removes the attack surface outright. If it does rely on network boot, keep boot traffic on an isolated segment, watch for exploit attempts, and press your board or server vendor for a firmware update that names CVE-2026-97631. Virtual machines matter too: OVMF, the EDK II-based UEFI firmware for VMs, is among the affected packages.
Why it matters for India readers
No Indian victim is named anywhere in the reporting, and this post claims none — the flaw is not an attack, it is an exposure. But the exposure maps directly onto India's infrastructure. Indian data centres, cloud providers, large enterprises and government systems run the same EDK II-based server firmware, and PXE is the standard way fleets of servers are provisioned and re-imaged. A flaw that lets an attacker run code before Secure Boot, on any machine caught mid-network-boot, is exactly the kind of risk India's IT teams should be inventorying now — before vendor firmware exists, not after. The checklist is short: find every system that PXE-boots, turn PXE off everywhere it is not needed, isolate boot traffic, and track your OEM's firmware page for a CVE-2026-97631 update. The same "edge and management devices are the battleground" theme runs through October's other big stories — our Warp Panda VMware ESX flaw CISA KEV explainer, our Cisco ASA FTD VPN flaw exploited explainer and our Fragnesia Linux kernel flaw CISA KEV explainer.
Should you care?
✅ Verdict: Yes, if you run servers or network-booted fleets — inventory your PXE-booting systems today and switch PXE off where it is not needed, because the patch pipeline for firmware is slow and the exploit details are already public. ⏳ Everyone else can watch and wait: if your machines boot from their own disks, this flaw does not reach you, and there is no sign of exploitation yet.
FAQs
What is CVE-2026-97631?
A critical buffer overflow in the PXE network-boot driver of TianoCore EDK II, the open-source code underneath most server UEFI firmware. It scores 9.5 out of 10 and can let an unauthenticated attacker run code before the operating system loads.
Am I affected if my computer boots from its own disk?
No. The flaw only triggers while a machine is booting over the network (PXE). Machines that boot solely from a local disk — nearly every home and office PC — fall outside the reported exposure.
Is there a patch for CVE-2026-97631 yet?
The fix exists in EDK II master source code since 15 October 2026, and Microsoft's Project Mu fork has backported it — but no stable EDK II release carries it, and as of 28 October no vendor firmware update listing the fix had appeared. Check your board or server vendor's support page.
Has CVE-2026-97631 been exploited?
No exploitation has been reported, and as of 29 October the flaw does not appear in CISA's Known Exploited Vulnerabilities catalogue. The risk is that the patch code is public, so capable attackers can work out the trigger before firmware updates ship.
What should server admins do right now?
Turn off PXE and the UEFI network stack on machines that never network-boot; isolate boot traffic on its own segment for machines that do; and watch your vendor's firmware releases for an update naming CVE-2026-97631.
Takeaway: A 16-year-old counting bug in the firmware underneath most servers can hand an attacker the machine before any security software exists — but only during network boot, and only with a tuned exploit. Switch PXE off where you do not need it, and wait for your vendor's firmware, not for a headline.
Follow World Tech on TechByCountry for tomorrow's 6 PM update.
📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.
Sources
- TianoCore — Pre-boot RCE in EDK II PXE driver (advisory GHSA-99cj-7hg9-mp4m, 22 October 2026)
- Hardware Busters — EDK II vulnerability lets a rogue ICMP packet run code before Secure Boot (28 October 2026)
- Brandefense — EDK II PXE vulnerability: who has a fix? (patch status checked 28 October 2026)
- SaveDelete — UEFI PXE boot flaw CVE-2026-97631 explained for servers (29 October 2026)
- Daily Inference — Network-booting servers can run attacker code before security starts (27 October 2026)
Comments
Post a Comment