Securify

A critical buffer overflow hiding in plain sight for sixteen years now puts virtually every server that network-boots at risk of pre-OS code execution — and no stable firmware release includes a fix yet.

What Happened

On October 22, 2026, the TianoCore project published advisory GHSA-99cj-7hg9-mp4m for CVE-2026-97631, a 9.5/10-severity buffer overflow in EDK II, the open-source reference implementation that underpins UEFI firmware across nearly every modern server. The flaw sits in EDK II’s PXE (Preboot Execution Environment) network-boot driver — the code that runs when a machine pulls its operating system image over the network instead of from a local disk.

Researchers Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) discovered the vulnerability, which traces back to a November 2010 commit. It was supposed to stay under wraps until a coordinated disclosure in January 2027. Instead, a public pull request filed by an AMI engineer on September 28 inadvertently described the bug by CVE number and included the fix, ending the embargo months early and giving attackers a head start.

How the Exploit Works

The root cause is deceptively simple. During a PXE network boot, the EDK II driver copies incoming ICMP error and status messages into a fixed 504-byte buffer. The size checks on both the IPv4 and IPv6 code paths are wrong: they fail to reject messages longer than the buffer can hold. An oversized message overflows adjacent memory.

To trigger it, an attacker needs to be on an adjacent network segment and send a single crafted packet while the target machine is mid-network-boot. No credentials, no prior access, and no user interaction are required. Red Hat and SUSE have independently confirmed the adjacent-network attack vector.

The most likely result of exploitation is a crash that hangs the boot process — a denial-of-service that could be devastating in a data center at scale. But the more alarming scenario is arbitrary code execution. Because PXE runs before Secure Boot and the operating system load, any code an attacker manages to execute operates at the firmware level, beneath the reach of endpoint detection, antivirus, or OS-level security controls. Reinstalling the operating system or even swapping the hard drive would not remove it.

HD Moore, a security researcher at Dragos, warned that a successful exploit could also expose TPM-dependent disk encryption keys to a short-term network attacker — a nightmare scenario for organizations relying on full-disk encryption to protect data at rest.

That said, achieving code execution is not trivial. The exploit must be tailored to the exact firmware build running on the target, which varies by vendor, model, and patch level. Security experts expect this to be most useful to nation-state actors and well-resourced threat groups rather than opportunistic attackers.

Who Is Affected

The scope is staggering. EDK II is not one vendor’s product — it is the shared foundation that AMI, Insyde, Phoenix, and Microsoft’s Project Mu all build upon. That means firmware from nearly every major server and motherboard manufacturer traces back to this codebase. The National Vulnerability Database classifies the bug as affecting BIOS through both “Out-of-bounds Write” and “Classic Buffer Overflow” weaknesses.

Confirmed affected software includes EDK II through the edk2-stable202608 release (August 21, 2026), as well as downstream packages in Red Hat Enterprise Linux 8, 9, and 10, plus SUSE and Debian distributions that ship EDK II-based firmware for virtual machines and servers.

There is some good news on the edges. Intel says no current commercial products under active security support are known to be vulnerable. Arm says the flaw is not directly applicable to its products. But AMD, Phoenix, AMI, Amazon, and Microsoft either declined to comment or did not respond before the advisory went public, leaving their patch status unclear.

The primary risk falls on enterprise and data center environments — organizations running large fleets of servers that PXE-boot from the network, including thin-client deployments, cloud infrastructure, and high-performance computing clusters. Typical home and office PCs that boot from a local SSD or hard drive are not affected.

The Patch Situation

A fix (pull request #13302) was merged into the EDK II main branch on October 15. The patch itself is straightforward: it truncates oversized ICMP messages at the 504-byte boundary. Eclypsium’s Jesse Michael described it as a basic code change that does not require certificate revocation or key management — a relative rarity for firmware bugs.

The problem is the delivery pipeline. No stable EDK II release includes the fix yet. Each downstream firmware vendor — AMI, Insyde, Phoenix, and others — must integrate it into their own builds, test it against the specific hardware platforms they support, and ship updates to their OEM customers, who then distribute them to end users. This process typically takes months. Microsoft’s Project Mu is the sole exception so far, having tagged builds containing the fix on October 26.

Compounding the urgency, the patch code has been public since the accidental September disclosure. Security researchers and vendors have warned that sophisticated adversaries have had over a month to study the fix, reverse-engineer the vulnerability, and develop exploits — all before most organizations can apply a patch.

The TianoCore advisory lists no official workaround. As of October 28, CISA’s Known Exploited Vulnerabilities catalog had not yet listed the flaw, and no exploitation in the wild has been confirmed.

What You Should Do Now

Organizations should take several concrete steps while waiting for firmware patches to arrive.

Disable PXE boot where it is not needed. PXE is enabled by default in the standard EDK II build, but many servers do not actually require network booting. Turning it off in the BIOS or UEFI configuration eliminates the attack surface entirely for those machines.

Segment and monitor boot-time network traffic. Since exploitation requires adjacent-network access during the brief PXE boot window, strict network segmentation between management and production networks reduces exposure. Monitoring for anomalous ICMP traffic on boot VLANs can provide early warning.

Contact your firmware vendor. Reach out to your server or motherboard manufacturer to ask about their timeline for shipping the fix. Organizations running Red Hat, SUSE, or Debian should watch for updated edk2 packages.

Audit your boot configurations. Identify which servers in your fleet actually PXE-boot and prioritize them for patching. Servers that boot from local storage are not at risk from this specific flaw.

Watch for CISA KEV updates. If the vulnerability is added to the Known Exploited Vulnerabilities catalog, federal agencies and their contractors will face mandatory patching deadlines, and private organizations should treat it as a signal to accelerate their own timelines.

This is the second major PXE-related vulnerability family in EDK II in under three years, following the nine-flaw “PixieFail” disclosure in January 2024. The pattern suggests the pre-boot networking stack deserves far more scrutiny than it has historically received — and that organizations relying on network boot should treat firmware patching with the same urgency they give to operating system updates.