CVE-2026-97631: The 16-Year-Old UEFI PXE Vulnerability That Threatens Most Servers on Planet Earth

Here’s a thought experiment. An attacker on your data-center VLAN wants to compromise a server that’s reinstalling its OS. They don’t need credentials, a phishing email, or an unpatched kernel — just one unauthenticated ICMP error message, longer than 504 bytes, fired at the machine during the brief, hard-to-time window it spends PXE booting. That single packet writes attacker-controlled data into the firmware’s pre-boot UEFI environment.

That is CVE-2026-97631 — the UEFI PXE vulnerability disclosed in the PXE network-boot driver of TianoCore EDK II, the open-source foundation that virtually every major UEFI supplier builds on — and it is not a thought experiment. It’s a buffer overflow rated 9.5 out of 10 by its reporters, and the code has, per Ars Technica’s reporting, been broken for about sixteen years.

Why does that matter so much? Because code that runs in UEFI runs before everything. Before the operating system’s hardening, before disk-encryption tools like LUKS or BitLocker decrypt a byte, and before the chain of trust that Secure Boot establishes — including the TPM measurements taken during boot — has verified a single OS component. As the TianoCore advisory’s summary puts it, an attacker who can deliver ICMP error messages to a PXE-booting machine can “corrupt DXE-phase memory and execute arbitrary code before the operating system loads, before Secure Boot or measured boot has verified or measured any OS component.”

HD Moore, Metasploit’s creator and chief research officer at Dragos, told Ars Technica that an attacker could use the CVE-2026-97631 flaw to “hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s TPM,” and that it could be used to break disk encryption in scenarios where an attacker has short-term network access — and even more easily in a theft scenario.

Before you panic-pull the console cable: this UEFI PXE vulnerability applies only to network-booting machines. If every machine in your fleet boots from local disks, you’re not affected. And a precision note: the vulnerable code is the PXE Base Code driver specifically — so per the advisory’s scope, a machine that HTTP-boots without using PXE sits outside the documented attack path for CVE-2026-97631. But in data centers, cloud environments, and enterprise labs, PXE boot is everywhere — and it’s enabled by default in a lot of firmware.

The CVE-2026-97631 Bug: 504 Bytes of Firmware History

Let’s look under the hood, because the mechanics of this UEFI PXE vulnerability are beautifully, painfully simple.

A copy loop that trusted the packet

PXE (the Preboot eXecution Environment) is the feature that lets a machine boot from an image downloaded over the network — the classic mechanism for provisioning racks of identical servers. While a machine is PXE booting, its firmware driver (specifically the PXE Base Code driver, NetworkPkg/UefiPxeBcDxe in EDK II) keeps a network listener open, waiting for ICMP error messages that its boot attempts might generate.

Here’s the problem, in the words of the GHSA advisory:

During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length.

Conceptually, the mistake looks like this (illustrative pseudocode, not the actual upstream code):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Simplified illustration of the bug class
#define ICMP_ERROR_MAX 504
UINT8 Mode_IcmpError[ICMP_ERROR_MAX];

void OnIcmpError(UINT8 *msg, UINTN remaining_length) {
    UINTN offset = 0;
    while (remaining_length > 0) {
        UINTN chunk = remaining_length;      // ❌ should be
                                             // MIN(fragment_size, 504 - offset)
        CopyMem(&Mode_IcmpError[offset], msg, chunk);
        offset  += chunk;                    // ❌ walks past the buffer
        msg     += chunk;
    }
}

The fixed 504-byte destination field exists precisely to hold ICMP errors — and the code copying into it simply doesn’t respect that limit. Two independent flaws compound: oversized messages get copied anyway, and the destination pointer advances by cumulative rather than per-fragment lengths, so even modestly mis-sized traffic walks the write pointer off the end of the structure.

One bug, two outcomes

The advisory describes two exploitation outcomes for CVE-2026-97631. Outcome (a) is the easy one: deterministic corruption of the driver’s private data and a CPU exception inside the DXE core on the next ICMP error, which simply hangs the boot. That’s a denial of service against OS provisioning or recovery — annoying, but on patch day, a boot-hang across your fleet is a real operational problem.

Outcome (b) is the scary one. An attacker who knows the target’s specific firmware build can plant a “counterfeit event” in the same packet and have CoreSignalEvent() dispatch attacker-supplied bytes in the DXE phase — running at ring 0, the CPU’s most privileged level, “before any OS security control exists,” per the advisory. Because the payload executes before boot-time attestation, Ars Technica’s reporting notes that exploits like this present an opportunity to elevate limited privileges: the machine can’t provide cryptographic proof to the world that it boots intact, because it doesn’t. Code-execution flaws in foundational libraries have a way of cascading across an ecosystem — the same month saw a config-parsing RCE disclosed in Hugging Face Transformers, another piece of infrastructure that nearly everyone depends on and few people audit.

Two important limits, both stated clearly in the sources. First, the exposure window is exactly the duration of the PXE boot — this isn’t a persistent backdoor in the firmware image; payloads run once, though they can open a door for installing payloads that do recur each boot, per Ars. Second, Eclypsium principal researcher Jesse Michael told Ars that exploiting the vulnerability requires guessing specific addresses within the target: “it’s not something that you can throw a single exploit at any target and get RCE across a diverse range of devices, but it needs to be tuned for each target model/version/configuration.”

Sixteen years of open network ports

Both Ars Technica and Hackaday’s This Week in Security column describe CVE-2026-97631 as a 16-year-old bug. Think about what that spans: every server generation that has PXE-booted EDK II-based firmware for a decade and a half has carried it.

Even more uncomfortable: this exact driver was already a known crime scene. PixieFail, disclosed in 2024, found nine vulnerabilities in the same family of EDK II network-boot code. That discovery kicked off dedicated fuzzing projects against EDK II — and, as Ars notes, those efforts appear to have missed this one. Sixteen years of shipping, a 2024 spotlight aimed directly at this subsystem, and a follow-up fuzzing campaign all failed to catch a straightforward heap-adjacent write in one of the most security-critical code paths on the planet. That’s worth sitting with.

Who Is Affected by the UEFI PXE Vulnerability

The EDK II supply chain

EDK II isn’t a product any admin ever bought. It’s the open-source reference implementation from the TianoCore project that independent BIOS vendors (IBVs) turn into shipping UEFI firmware. Ars Technica reports that a UEFI Forum representative last year called EDK2 the “preeminent solution / implementation of the UEFI specifications,” and that virtually all UEFI suppliers — including AMI, Insyde, and Phoenix — use the reference code extensively. Microsoft’s hardened EDK2 fork, Project Mu, also used code containing the vulnerable component. This is the firmware-world expression of a pattern we’ve tracked across the modern software supply chain — most recently a trapdoor planted in an AI coding assistant’s build pipeline, which reached users through the very dependencies they trusted.

In other words, “threatens most servers on planet Earth” is a reasonable first approximation for CVE-2026-97631 — Hackaday’s writeup puts it as a bug “in most servers” — but it deserves nuance:

• It’s not an initial entry point into a network. An attacker needs some foothold in the network path — malicious insider, compromised segment, nation-state operator — during the boot sequence. Ars explicitly reports there’s no evidence of CVE-2026-97631 providing initial network access.
• Home and small-office users who boot from local disk are not affected.
• Not every firmware tree contains the affected code. Intel told Ars that none of its commercial products under security support are known to be affected, and that Intel’s reference code doesn’t include the affected EDK2 functionality — though that code may be integrated by OEM board vendors. Arm told Ars that “CVE-2026-97631 is not directly applicable to Arm’s product portfolio.” At the same time, Ars points out that Intel’s published reference code on GitHub makes reference to EDK2, and TianoCore documented each Intel UEFI development kit as a validated implementation “for a specific revision of the EDK II source.” Confusing? Yes. That’s the point.

The honest takeaway, which Ars also lands on: even if some platforms are free of EDK2 code, every server operator should investigate whether this UEFI PXE vulnerability affects them. Ars reports that questions to AMD, Phoenix Technologies, AMI, Microsoft, and Amazon went unanswered when their story went live, so the full affected-vendor picture is still filling in.

Who is talking? Supermicro is. Its October 2026 advisory acknowledges CVE-2026-97631 in EDK II-based firmware as critical (9.5, with a CVSS:4.0 vector noting the attack-time prerequisite AT:P) and lists affected Intel- and Ampere-based product lines spanning X11 through X14 generations — Greenlow, Purley, Whitley, Eagle Stream, Granite Rapids, and more — with fixed BIOS versions and, notably, many older boards marked “By request” rather than shipping fixes outright. Supermicro also states it is not aware of any public announcements or malicious use of the vulnerabilities described in the advisory — no known exploitation, on the vendor’s record, as of its publication.

The Disclosure That Didn’t Wait

Quick context, because we’ve been here before — I covered the php2shell early-leak panic just two weeks ago.

The short version: researchers Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) discovered the bug and arranged coordinated disclosure for January. Then AMI — which signed its fix on GitHub — published a pull request with the fix publicly on September 28, 2026. For the timeline pedants (and this story deserves them): that AMI pull request, #13200, was closed without being merged — the fix that actually landed upstream is a separate, maintainer-authored PR #13302, created October 14 and merged October 15. Once the discovering parties noticed, TianoCore published its public advisory GHSA-99cj-7hg9-mp4m on October 22, 2026, and the upstream fix was public record (the flaw is also tracked by CERT/CC as VU#132380). Hackaday’s dry summary: “TianoCore had little choice but to publish an advisory.”

Ars frames what comes next bluntly: with publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and build working exploits.

Patching the UEFI PXE Vulnerability Is Not a Tuesday Reboot

Here is the uncomfortable operational reality: the fix for CVE-2026-97631 exists in EDK II today — PR #13302 merged into upstream on October 15, 2026 — but your servers don’t run upstream EDK II. They run a vendor’s forked, configured, signed firmware image, months or years forked from upstream. Remediation for this UEFI PXE vulnerability therefore flows through OEM/IBV BIOS and UEFI update chains, not apt upgrade.

The GHSA itself, at publication, listed the affected package (NetworkPkg in EDK II, master as of 2026-09-14) with patched versions effectively not yet shipped downstream. That is the pattern, and it’s why Moore told Ars he expects this to be a “forever” bug living on in end-of-support systems.

Here’s what your first two days should actually look like.

Day 1: inventory — do you even PXE?

First, determine whether your fleet is exposed to CVE-2026-97631. Check the machine’s boot configuration from the OS side:

1
2
3
4
5
6

# Identify the BIOS/UEFI vendor and version
sudo dmidecode -t bios | grep -E "Vendor|Version|Release Date"

# On modern machines: check the boot entries that exist
# (a network entry doesn't mean it's USED, but it means the stack is present)
efibootmgr -v 2>/dev/null || ls /sys/firmware/efi/efivars

Then compare the firmware vendor and version against your OEM’s advisory — and if your vendor has published nothing, ask them. That’s the single most effective action available this week, and it’s what Ars’s reporting recommends first. Silence from IBVs right now is itself a finding.

Day 2: shrink the window

• Disable network boot where you don’t need it. Most provisioned machines never boot from the network again after deployment. In the firmware setup, move local disks above network boot in UEFI boot order, or explicitly disable the network/PXE boot entry. This doesn’t fix the bug, but it closes the exposure window the advisory describes — “the duration of the PXE boot.” Ars, for its part, frames this as an interim measure — suggesting affected organizations consider turning off network boot “at least temporarily if possible” while awaiting firmware fixes — not as a standing replacement for patching.
• Segment and monitor the PXE path. The attack behind CVE-2026-97631 is a unicast ICMP error message delivered to the client’s IP during network boot, from any network distance. Anything you can do to keep provisioning VLANs away from untrusted hosts — and to log unusual ICMP traffic on those segments — buys you detection surface. Ars also recommends monitoring logs for signs of exploitation attempts.
• Keep Secure Boot and TPM on anyway. They won’t stop this particular UEFI PXE vulnerability, as Ars notes, but they’re still what makes the rest of your boot chain verifiable — and you’ll want them intact when patches arrive.
• Plan the patch campaign now. Supermicro’s advisory shows the shape of the good case: many current-generation boards already have fixed BIOS versions to deploy, but a long tail of older systems is only available “by request.” Budget the maintenance windows; firmware updates don’t roll out like OS patches, and there’s no such thing as a hotfix for Signed ROM.

One genuinely useful point from Jesse Michael at Eclypsium, reported by Ars: unlike the Secure Boot bypasses of recent years (BlackLotus, BootHole-class bugs), this fix “doesn’t need to deal with revocations, pk/kek/db/dbx key management updates, or making sure to update OS and provisioning media.” It’s a plain code fix in a driver. Painful to ship, but clean to apply. Small mercies.

If you’re a Linux shop running OVMF (QEMU/KVM firmware), note that the oss-security discussion of CVE-2026-97631 reports Debian’s security tracker marking OVMF as vulnerable with no fixes on any release yet, as of October 28. Hypervisor host firmware and guest firmware are two separate patching tracks — don’t let the first distract you from the second.

What CVE-2026-97631 Says About Firmware Security

Step back from this one UEFI PXE vulnerability and look at the pattern:

One buffer overflow, in one driver, in a shared open-source foundation used by practically every firmware vendor, survived sixteen years of exposure and a targeted, post-PixieFail fuzzing effort aimed squarely at that subsystem. The upstream community fixed it in one merged pull request within weeks of it becoming public. The hard part isn’t the fix — it’s propagating a merged commit through the forks, the IBVs, the OEMs, the data centers, and into the flash on millions of boards, some of which will never see an update at all.

That asymmetry — days to fix upstream, years to fix downstream — is what makes pre-boot code the next frontier. Attackers don’t need to defeat Secure Boot when they can strike below it — the same lesson as GhostLock, where a single kernel bug dissolved the container isolation boundary everyone assumed was enforced. Defenders, meanwhile, spend their patch budgets at the OS layer because that’s where patching works.

So if you run servers, your CVE-2026-97631 checklist is three lines long: figure out whether your machines PXE-boot; turn it off wherever it’s not needed; and start chasing your firmware vendor for a fixed BIOS today. The sixteen-year clock already ran on this bug. The question left is how long you’ll run it.

References and further reading

• TianoCore EDK II security advisory GHSA-99cj-7hg9-mp4m — the official advisory for CVE-2026-97631
• AMI pull request #13200 — the publicly visible fix PR, published September 28, 2026 and closed without merge
• Upstream fix PR #13302 — the maintainer-authored PR merged into EDK II on October 15, 2026
• Supermicro security advisory: PXE Network Boot Buffer Overflow in EDK II, October 2026 — affected product lines and fixed BIOS versions
• oss-security: CVE-2026-97631: Pre-boot RCE in EDK II PXE driver — mailing-list disclosure, including OVMF status
• Ars Technica: Code-execution flaw in UEFI firmware threatens most servers on planet Earth — Dan Goodin’s reporting, with commentary from HD Moore and Jesse Michael
• Hackaday: This Week In Security — Broken Embargoes, UEFI Overflow, Wormable Tailscale, Starlink Ad Snooping, And A DHS Directory Dump
• Quarkslab: PixieFail — nine vulnerabilities in TianoCore’s EDK II UEFI firmware — the 2024 disclosure in the same network-boot subsystem
• CERT/CC Vulnerability Note VU#132380 — CERT coordination tracking for the EDK II PXE flaw

• Next Post →