EDK2 vulnerability compromises secure boot for most of the world's servers

What was discovered

Researchers found a code execution vulnerability rated 9.5 on a 10-point scale in TianoCore EDK II (EDK2), the open-source reference code used by nearly every UEFI firmware vendor on the market. The flaw was catalogued as CVE-2026-97631 and affects the driver that lets servers boot over the network using the PXE standard. According to Wired, the bug was found by Alex Matrosov, a researcher at Anthropic, and Dan Holmes, of Google.

The pair had agreed with vendors on a coordinated disclosure planned for January. The plan didn't hold: motherboard maker AMI published, last month, a public pull request detailing the flaw and including the fix. The document went unnoticed until it was spotted by the researchers who found the bug themselves, which forced the TianoCore Project to publish an official advisory last week, months ahead of the agreed schedule.

The case recalls another recent episode: six days earlier, two critical vulnerabilities in the PHP language also leaked ahead of schedule and were already being exploited at scale by the time they became public, according to another report from Wired itself.

Why this matters for infrastructure

EDK2 is not just any piece of software: it's the base on which vendors like AMI, Insyde, and Phoenix build the UEFI firmware that runs the instant a server powers on, before the operating system and before any security mechanism such as Secure Boot. Microsoft's hardened fork, Project Mu, also inherited the vulnerable component.

That means the compromised code runs at a moment when the boot chain of trust is still being built. A successful attack executes in ring 0, the CPU's highest privilege level, and bypasses the attestation processes that cryptographically prove the hardware is intact, including the TPM.

In short: when the flaw is exploited, it acts before any operating system defense exists, including Secure Boot.

Where the bug lives and how it's triggered

The problem is a 16-year-old buffer overflow in the NetworkPkg/UefiPxeBcDxe driver, responsible for the PXE Base Code used during network boot. During that process, the driver keeps a listener open for ICMP error messages and copies each one into a fixed 504-byte field called Mode.IcmpError.

The official TianoCore advisory describes the flaw precisely:

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.

TianoCore Project, official EDK2 advisory

In practice, an attacker with some level of access to the local network, during a target's PXE boot sequence, can send a single oversized unicast ICMP message. Without knowing the exact build of the target firmware, the result is just a crash, a denial of service. Knowing the build, the attacker can plant a spoofed event that executes malicious code on the CPU inside the UEFI firmware environment itself.

Who needs to worry (and who doesn't)

The flaw doesn't affect home users or machines that boot only from disk. It's relevant only to organizations with equipment that boots over the local network, or, in theory, through resources accessible over the internet, provided the firmware uses EDK2 and has PXE enabled, which comes on by default on most equipment.

That narrows the problem down to exactly the audience that operates servers, storage, and other infrastructure equipment: in-house data centers, colocation providers, and private clouds that use network boot for mass provisioning, a common practice in bare-metal operations anywhere in the world, including Brazil.

Intel told Wired that none of its "currently security-supported commercial products" is known to be affected, although it acknowledges that board makers may integrate the vulnerable code on their own; Intel's own public documentation references EDK2 extensively. Arm gave a similar response, stating that the CVE "doesn't directly apply" to the company's portfolio, even though its reference firmware also uses code inherited from EDK2.

AMD, Phoenix Technologies, AMI, Microsoft, and Amazon did not respond to Wired's requests for comment by the time the original story was published. Without an official, complete list of who uses what, it falls to each infrastructure team to audit its own hardware fleet.

Not every exploitation is trivial

HD Moore, creator of Metasploit and chief research officer at Dragos, explained to Wired why the bug is especially troublesome for those who rely on disk encryption:

This vulnerability in the ICMP parser of the EDK2 network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem. An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint's TPM. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario).

HD Moore, creator of Metasploit and chief research officer at Dragos

Jesse Michael, principal researcher at Eclypsium, notes that it's not a generic one-click exploit for every target: the attacker needs to guess specific memory addresses, which requires tailoring the attack to each firmware model, version, and configuration. He also points to a rare upside in this case: unlike previous Secure Boot flaws such as BootHole and BlackLotus, the fix for CVE-2026-97631 doesn't require key revocation or updating provisioning media, just applying a conventional BIOS/UEFI update.

One more chapter in a list that keeps growing

CVE-2026-97631 joins a lengthy list of flaws in UEFI or in code close to it. The most severe to date, LogoFail, came from rendering bugs in the logo images bundled into the UEFI of nearly every hardware vendor. PixieFail, the case most similar to this one, also stemmed from flaws in EDK2's PXE boot, and prompted rounds of fuzzing that, evidently, didn't catch this bug. The list continues with PKFail, a supply-chain flaw tied to test keys that leaked for over a decade, plus BootHole, Bootkit, and BlackLotus.

HD Moore classified CVE-2026-97631 as a "forever" bug: given the volume of devices with EDK2 embedded and out of support, it's expected to survive for years on systems that will never receive the patch.

What to do

For those who manage servers, bare metal, or private cloud infrastructure in Brazil or elsewhere, the list of possible actions is short, but concrete:

• Check with the firmware vendor (motherboard, server, or appliance) whether the equipment uses EDK2 and whether a BIOS/UEFI update is already available;
• Temporarily disable network boot (PXE) on machines that don't depend on it for day-to-day provisioning;
• Keep TPM and Secure Boot enabled even knowing they don't block this specific attack, because they still protect against other classes of threats;
• Monitor network logs for exploitation attempts during PXE boot sequences.

Since the fix has been public ever since AMI's unplanned publication, the time to act is short: anyone with read access to the pull request can reconstruct the path to a working exploit, even though, as Michael points out, each exploit needs to be tailored to the specific target.