A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver
---
published: true
tags: security, firmware, uefi, infosec
description: "A 16-year-old buffer overflow in TianoCore EDK II's PXE driver (CVE-2026-97631, 9.5) runs code in ring 0 before Secure Boot and TPM load. The fix diff, the embargo AMI broke a month early, the fleet audit - and the QEMU harness I built to reproduce it, documented honestly including where it stopped."
series: black box
---
> There is a buffer overflow in the network-boot driver of TianoCore EDK II - the open-source UEFI reference implementation that virtually every server BIOS on the planet derives from - and it has been there for sixteen years. CVE-2026-97631, rated 9.5: during a PXE network boot, an oversized ICMP error message writes attacker-controlled bytes past a 504-byte struct, corrupting firmware memory - code execution in ring 0, before Secure Boot and TPM even load. Found by Alex Matrosov and Dan Holmes. And the disclosure itself broke: AMI pushed the fix to a public repo a month ahead of the coordinated date, forcing an early advisory. The fifth disclosure-pipeline failure of the month, on the blog that has been counting them.
This post: the mechanism from the actual fix diff, what the bug does and doesn't give an attacker, the embargo story, a fleet audit you can run in one line - and the headless QEMU harness I built to reproduce it (now on GitHub: slabbdev/uefi-pxe-cve-2026-97631), documented to the exact point where my hardware said no.
The bug, read from the fix
The vulnerable code lives in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c - the handler that processes ICMP error messages arriving while the firmware network-boots. Here is the actual buggy loop, from the repo, before the patch (PR #13200, opened Sept 28):
CopiedLen = 0;
IcmpError = (UINT8 *)&Mode->IcmpError; // EFI_PXE_BASE_CODE_ICMP_ERROR = 504 bytes
for (Index = 0; Index < RxData->FragmentCount; Index++) {
CopiedLen += RxData->FragmentTable[Index].FragmentLength; // (1)
if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
CopyMem (IcmpError, ...FragmentBuffer, ...FragmentLength); // (2)
} else {
CopyMem (IcmpError, ...); // the else branch copied too - truncated in the diff, same object
}
}
Two textbook flaws stacked: the bound is checked against the cumulative length after adding the fragment (1), and a copy happens in both branches (2). Craft an ICMP error whose quoted payload exceeds 504 bytes - trivially, since the ICMP error body is just "original datagram" bytes you control - and the writes run past the end of the IcmpError struct inside the firmware's DXE phase. The fix introduces a FragmentLen variable and copies strictly bounded amounts per fragment.
What that buys an attacker, precisely: memory corruption in ring 0, in firmware, during the boot window - before the OS, before Secure Boot's runtime protections matter, before TPM-measured boot captures anything sane. The researchers note it can bypass remote attestation and break disk encryption assumptions. What it does NOT buy: this is not an internet-facing RCE. You need a position on the local network, a target that actually does PXE network boot (datacenter servers, fat clients - not your laptop booting from disk), and per-model tuning of the exploit. It is an insider/nation-state/ransomware escalation tool, not a worm.
The disclosure that broke
The coordinated embargo targeted January. Then AMI - an IBV whose BIOS AMI, Insyde, Phoenix and OEMs ship - published the fix pull request on September 28, a month early, blowing the timeline and forcing the early advisory. The PR is still there, timestamped, from an AMI engineer. Ars asked AMD, Phoenix, AMI, Microsoft and Amazon for comment; none answered. Intel and Arm claim their products aren't directly affected, though both borrow from EDK II lineage.
The month's disclosure-failure scoreboard, for those keeping count: LiteLLM reposted with scrambled dates, ZDI's private queue leaked to the public LKML, eMudhra blamed "amplification", a measured PHP advisory got dressed as BREAKING - and now an IBV broke its own embargo. Five failures, five different mechanisms, one lesson: the pipeline around the vulnerability is the vulnerability.
Audit your fleet - one line
PXE is on by default on most server firmwares. The audit:
# any network-boot entries in the firmware boot order?
efibootmgr -v | grep -iE 'pxe|network|ip4|ip6'
# BMC angle: many boards can enable network boot remotely - check yours
ipmitool lan print 1 # if the BMC is reachable, PXE policy is BMC policy
If nothing boots from the network and nothing can turn it on remotely, this CVE is not your fire today - but the patch wave is coming through your BIOS vendors over the next months, and unlike Secure Boot key rollovers, this one is a normal firmware update. Add "EDK II PXE fix" to the checklist of the next BIOS refresh cycle; disable network boot entirely on machines that never PXE.
The harness - what I built, what worked, what didn't
I tried to reproduce the crash locally, headless, on the exact vulnerable code. The harness (three small files, in the repo) is genuinely reusable for any OVMF boot-testing:
- bridge.py - a Python DHCP server + attack tool on the QEMU wire: binds the QEMU socket UDP netdev pair, answers DHCP DISCOVER/REQUEST, waits for the TFTP read request, then fires 6× ICMP type-3 code-1 errors quoting a 1,200-byte fake datagram into a struct with room for 504. Pure stdlib, no scapy.
- router.py - a screen-state router: classifies OVMF's screen from screendump pixel statistics (black = UEFI Shell, blue = front page/Boot Manager), then drives the headless firmware through the monitor (sendkey) into the Boot Manager and onto UEFI PXE IPv4 - no display, no VNC.
- QEMU config: OVMF pflash, virtio-net on a UDP socket netdev (no multicast flakiness), filter-dump pcap tap on the wire, -d cpu_reset to catch firmware triple-faults.
What worked: everything up to the PXE boot attempt, reproducibly. The firmware boots, the router navigates the Boot Manager blindly and lands on the PXE screen (Client MAC banner and all), the wire tap and reset counters are live, the DHCP/attack engine is armed.
What didn't: the homebrew QEMU-bundled OVMF builds (IA32 and X64, q35 and i440fx) display the PXE banner and then transmit zero packets - the DHCP Discover never leaves the firmware under TCG emulation, so the ICMP trigger never arrives at the vulnerable handler. Reproducing further needs a serial-debug OVMF build (or a real machine with PXE enabled, which I won't point an overflow at outside a lab). The harness is documented to this exact boundary on purpose: it's the difference between "I ran it" and "I read it", and today this post is honest about being the second with the doors open for the first.
TL;DR
Sixteen-year-old overflow in the UEFI network-boot driver, ring 0 before your defenses load, local-network attack on PXE-booting fleets - patched in EDK II and rolling out through every BIOS vendor now. Check your boot order (efibootmgr), disable network boot where you don't need it, and add the fix to your firmware refresh checklist. The disclosure broke a month early, which is somehow the least surprising sentence of October.
Sources: Ars Technica - Code-execution flaw in UEFI firmware · EDK II fix PR #13200 · EDK II fix PR #13302 · Harness repo: slabbdev/uefi-pxe-cve-2026-97631
5 reactions
Mentions
Hetzner status: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component Not sure if everyone saw this one, but good to check if it applies to you: A critical security vulnerability has recently been identified in the EDK II UEFI firmware component (CVE-2026-97631, CVSS 9.5). Further details can be found in the advisory: https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m What is affected? The vulnerability affects systems that boot over the network using PXE. During the boot process, an attacker may be able to execute malicious code through specially crafted network packets, even before the operating system and its security mechanisms (e.g., Secure Boot) are active. Systems that are already running are not directly at risk; the vulnerability can only be exploited during a PXE boot. An official patch is not yet available. What do we recommend? As an immediate precautionary measure, we recommend avoiding reboots of your hosts until further notice if they use PXE boot. What happens next? We are currently analyzing the impact on our environment and developing further recommendations and additional protective measures. We will inform you promptly as soon as new findings or updates become available. Source: Hetzner status
TianoCore disclosed CVE-2026-97631 (9.5) in EDK II's PXE boot driver. Crafted ICMP errors during network boot may hang affected systems or permit targeted pre-OS code execution. For MSPs/admins: inventory PXE-boot systems, disable network boot where unused, isolate provisioning traffic, and check for vendor firmware updates. Exposure is during PXE boot, not every startup. TianoCore lists no patched release. github.com/tianocore/edk2/security/advisories/GHS…
記事に気付いてなかったから、今後は定期的に巡回しておこうかな… github.com/tianocore/edk2/security/advisories
Pre-boot RCE in EDK II PXE driver CVE-2026-97631
🚨🇺🇸 Critical 16-year-old EDK II flaw enables code execution before Secure Boot A critical buffer overflow in TianoCore EDK II, the open-source foundation used to build much of the world’s UEFI firmware, can allow an unauthenticated attacker to run code before the operating system loads. Tracked as CVE-2026-97631, the vulnerability carries a CVSS score of 9.5 and has existed in the code since November 2010. ⠀ The flaw resides in the PXE network-boot driver, which copies incoming ICMP error messages into a fixed 504-byte buffer without properly limiting their size. ⠀ An attacker who can reach a machine while it is booting over the network can send a crafted ICMP message that: • Crashes the firmware and prevents the operating system from loading • Executes attacker-controlled code in the pre-boot environment • Runs before Secure Boot and measured-boot protections evaluate the operating system ⠀ Reliable code execution requires knowledge of the target’s firmware build. Systems that boot exclusively from local storage are not exposed through this attack path. ⠀ An upstream fix was merged into EDK II on October 15, but no stable EDK II release currently includes it. Server and motherboard vendors must integrate the patch and distribute BIOS or UEFI updates to customers. Source: github.com/tianocore/edk2/security/advisories/GHS…
Ping of death is back 💀 github.com/tianocore/edk2/security/advisories/GHS… TLDR; Ping during PXE boot can crash or get RCE because of vulnerability in UEFI. t.co
A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver --- published: true tags: security, firmware, uefi, infosec description: "A 16-year-old buffer overflow in TianoCore EDK II's PXE driver (CVE-2026-97631, 9.5) runs code in ring 0 before Secure Boot and TPM load. The fix diff, the embargo AMI broke a month early, the fleet audit - and the QEMU harness I built to reproduce it, documented honestly including where it stopped." series: black box --- > There is a buffer overflow in the network-boot driver of TianoCore EDK II - the open-source UEFI reference implementation that virtually every server BIOS on the planet derives from - and it has been there for sixteen years. CVE-2026-97631, rated 9.5: during a PXE network boot, an oversized ICMP error message writes attacker-controlled bytes past a 504-byte struct, corrupting firmware memory - code execution in ring 0, before Secure Boot and TPM even load. Found by Alex Matrosov and Dan Holmes. And the disclosure itself broke: AMI pushed the fix to a public repo a month ahead of the coordinated date, forcing an early advisory. The fifth disclosure-pipeline failure of the month, on the blog that has been counting them. This post: the mechanism from the actual fix diff, what the bug does and doesn't give an attacker, the embargo story, a fleet audit you can run in one line - and the headless QEMU harness I built to reproduce it (now on GitHub: slabbdev/uefi-pxe-cve-2026-97631), documented to the exact point where my hardware said no. The bug, read from the fix The vulnerable code lives in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c - the handler that processes ICMP error messages arriving while the firmware network-boots. Here is the actual buggy loop, from the repo, before the patch (PR #13200, opened Sept 28): CopiedLen = 0; IcmpError = (UINT8 *)&Mode->IcmpError; // EFI_PXE_BASE_CODE_ICMP_ERROR = 504 bytes for (Index = 0; Index < RxData->FragmentCount; Index++) { CopiedLen += RxData->FragmentTable[Index].FragmentLength; // (1) if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) { CopyMem (IcmpError, ...FragmentBuffer, ...FragmentLength); // (2) } else { CopyMem (IcmpError, ...); // the else branch copied too - truncated in the diff, same object } } Two textbook flaws stacked: the bound is checked against the cumulative length after adding the fragment (1), and a copy happens in both branches (2). Craft an ICMP error whose quoted payload exceeds 504 bytes - trivially, since the ICMP error body is just "original datagram" bytes you control - and the writes run past the end of the IcmpError struct inside the firmware's DXE phase. The fix introduces a FragmentLen variable and copies strictly bounded amounts per fragment. What that buys an attacker, precisely: memory corruption in ring 0, in firmware, during the boot window - before the OS, before Secure Boot's runtime protections matter, before TPM-measured boot captures anything sane. The researchers note it can bypass remote attestation and break disk encryption assumptions. What it does NOT buy: this is not an internet-facing RCE. You need a position on the local network, a target that actually does PXE network boot (datacenter servers, fat clients - not your laptop booting from disk), and per-model tuning of the exploit. It is an insider/nation-state/ransomware escalation tool, not a worm. The disclosure that broke The coordinated embargo targeted January. Then AMI - an IBV whose BIOS AMI, Insyde, Phoenix and OEMs ship - published the fix pull request on September 28, a month early, blowing the timeline and forcing the early advisory. The PR is still there, timestamped, from an AMI engineer. Ars asked AMD, Phoenix, AMI, Microsoft and Amazon for comment; none answered. Intel and Arm claim their products aren't directly affected, though both borrow from EDK II lineage. The month's disclosure-failure scoreboard, for those keeping count: LiteLLM reposted with scrambled dates, ZDI's private queue leaked to the public LKML, eMudhra blamed "amplification", a measured PHP advisory got dressed as BREAKING - and now an IBV broke its own embargo. Five failures, five different mechanisms, one lesson: the pipeline around the vulnerability is the vulnerability. Audit your fleet - one line PXE is on by default on most server firmwares. The audit: # any network-boot entries in the firmware boot order? efibootmgr -v | grep -iE 'pxe|network|ip4|ip6' # BMC angle: many boards can enable network boot remotely - check yours ipmitool lan print 1 # if the BMC is reachable, PXE policy is BMC policy If nothing boots from the network and nothing can turn it on remotely, this CVE is not your fire today - but the patch wave is coming through your BIOS vendors over the next months, and unlike Secure Boot key rollovers, this one is a normal firmware update. Add "EDK II PXE fix" to the checklist of the next BIOS refresh cycle; disable network boot entirely on machines that never PXE. The harness - what I built, what worked, what didn't I tried to reproduce the crash locally, headless, on the exact vulnerable code. The harness (three small files, in the repo) is genuinely reusable for any OVMF boot-testing: - bridge.py - a Python DHCP server + attack tool on the QEMU wire: binds the QEMU socket UDP netdev pair, answers DHCP DISCOVER/REQUEST, waits for the TFTP read request, then fires 6× ICMP type-3 code-1 errors quoting a 1,200-byte fake datagram into a struct with room for 504. Pure stdlib, no scapy. - router.py - a screen-state router: classifies OVMF's screen from screendump pixel statistics (black = UEFI Shell, blue = front page/Boot Manager), then drives the headless firmware through the monitor (sendkey) into the Boot Manager and onto UEFI PXE IPv4 - no display, no VNC. - QEMU config: OVMF pflash, virtio-net on a UDP socket netdev (no multicast flakiness), filter-dump pcap tap on the wire, -d cpu_reset to catch firmware triple-faults. What worked: everything up to the PXE boot attempt, reproducibly. The firmware boots, the router navigates the Boot Manager blindly and lands on the PXE screen (Client MAC banner and all), the wire tap and reset counters are live, the DHCP/attack engine is armed. What didn't: the homebrew QEMU-bundled OVMF builds (IA32 and X64, q35 and i440fx) display the PXE banner and then transmit zero packets - the DHCP Discover never leaves the firmware under TCG emulation, so the ICMP trigger never arrives at the vulnerable handler. Reproducing further needs a serial-debug OVMF build (or a real machine with PXE enabled, which I won't point an overflow at outside a lab). The harness is documented to this exact boundary on purpose: it's the difference between "I ran it" and "I read it", and today this post is honest about being the second with the doors open for the first. TL;DR Sixteen-year-old overflow in the UEFI network-boot driver, ring 0 before your defenses load, local-network attack on PXE-booting fleets - patched in EDK II and rolling out through every BIOS vendor now. Check your boot order (efibootmgr), disable network boot where you don't need it, and add the fix to your firmware refresh checklist. The disclosure broke a month early, which is somehow the least surprising sentence of October. Sources: Ars Technica - Code-execution flaw in UEFI firmware · EDK II fix PR #13200 · EDK II fix PR #13302 · Harness repo: slabbdev/uefi-pxe-cve-2026-97631
CVE-2026-97631 (UEFI PXE pre-boot RCE) It looks like Hetzner dedicated servers are affected by CVE-2026-97631 Is there a good way to protect them until Hetzner rolls out a BIOS update?
@matrosov Отличная работа!🔥🔥🔥 github.com/tianocore/edk2/security/advisories/GHS… edk2#13200 edk2#13302
One ICMP packet can hijack a PXE-booting server before Secure Boot checks the OS. CVE-2026-97631 (9.5): pre-boot RCE in TianoCore EDK II. RCE needs a build-specific payload. By @matrosov (Anthropic) + Dan Holmes-Mitra (Google): github.com/tianocore/edk2/security/advisories/GHS… #UEFI #SecureBoot #RCE t.co