Critical EDK2 UEFI flaw enables pre-boot code execution on most servers

A 16-year-old overflow in the UEFI network stack

Ars Technica reports that a critical vulnerability, tracked as CVE-2026-97631 and rated 9.5 out of 10, has been disclosed in TianoCore EDK2, the open source reference implementation of the UEFI specification. Independent BIOS vendors including AMI, Insyde and Phoenix build their firmware on this codebase, and Microsoft's hardened fork, Project Mu, also carried the vulnerable component — which is why the flaw is being described as reaching a large share of the world's servers and data centers.

The bug is a buffer overflow in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe), used when machines boot from code fetched over the local network, and it has reportedly been present for 16 years. During this pre-boot phase the driver listens for ICMP error messages and copies each one into a fixed 504-byte field, Mode.IcmpError. According to the advisory, the copy loop mishandles bounds in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): messages longer than 504 bytes are still copied, and the destination pointer advances by cumulative rather than per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier in the receive path caps the message size.

Code execution before the defenses load

An oversized ICMP error can arrive as a plain unicast aimed at the target's IP address — from any network distance — provided it lands during the PXE boot sequence. Ars Technica notes that a simple oversized message can hang the boot process for a denial-of-service. An attacker who knows the target's exact firmware build can go further and plant a "counterfeit event" that runs code inside the UEFI environment at ring 0, the CPU's most privileged level.

Because that code executes before the operating system and before mechanisms such as Secure Boot and the TPM come into play, it operates outside the boot chain of trust. HD Moore, chief research officer at Dragos, told Ars Technica that an attacker could hijack program flow while the boot process still has access to the TPM, potentially defeating disk encryption with only short-term network access — and more easily where hardware is physically stolen. Payloads delivered this way lack persistence and run only once, but they can serve as a staging step for other components that execute at every boot. Exploitation also sidesteps attestation checks meant to cryptographically prove to remote parties that hardware is trustworthy.

The embargo collapsed early

Alex Matrosov of Anthropic and Dan Holmes of Google, who discovered the flaw, had arranged a coordinated disclosure for January. That plan fell apart when AMI published a pull request last month containing the fix, which effectively revealed the vulnerability. TianoCore followed with a public advisory last week. With patch code now public, Ars Technica warns that skilled attackers will find it trivial to reconstruct the trigger and build working exploits, while rolling fixed firmware out to millions of devices across thousands of vendors and cloud providers is slow and cumbersome. The news lands six days after another mishandled disclosure, this one involving a critical flaw in PHP.

Constraints on attackers

Exploitation has real prerequisites. Some control over, or low-level access to, the local network is needed, which points to insiders or well-resourced actors such as nation-states and ransomware groups seeking to elevate privileges. Ars Technica reports no evidence that the bug works as an initial entry point into a network. Jesse Michael, a principal researcher at Eclypsium, also told the publication that an attacker must guess target-specific memory addresses and tune the exploit to each model, version and configuration, so it is not a universal one-shot exploit across diverse devices — though he noted that, unlike several earlier high-profile UEFI flaws, this one can be addressed with a basic fix.

Why it matters

CVE-2026-97631 joins PixieFail, LogoFail, PKFail, BootHole and BlackLotus in a growing line of firmware-level weaknesses that execute before operating system defenses exist. Its reach through EDK2 makes the patching surface enormous, and Moore expects it to live on as a "forever" bug in end-of-support systems, since many devices never receive firmware updates at all. The blown embargo means defenders have effectively no head start. Notably, the fuzzing efforts launched after PixieFail to scour EDK2 for similar flaws did not surface this one, raising questions about how many other long-lived bugs remain in code that nearly every server trusts at boot.