Exploits

EDK II Flaw: 16-Year-Old UEFI Boot Vulnerability

Eng. Donya Bino Published  ·  6 min read

Your servers might be carrying a 16-year-old vulnerability in the firmware that boots them, because a critical buffer overflow in EDK II, the open-source code that most hardware makers use to build UEFI firmware, can let an attacker run code before your operating system even loads.

The flaw is tracked as CVE-2026-97631, it carries a 9.5 severity rating from TianoCore, and the only condition is that the machine boots over the network. If you run a data center, this is not something you can ignore.

What the Flaw Actually Does

UEFI firmware is the software that runs first when a computer is switched on, before the operating system. An attacker who can reach the machine with a crafted network message during a network boot can hang the boot, or, with work tailored to the exact firmware build, run their own code before Secure Boot and other startup defenses load.

The flaw is a buffer overflow in EDK II's network-boot code, known as PXE. During a PXE boot, a machine loads its startup image from the network instead of from a local disk. The PXE driver listens for ICMP error messages and small status messages that network devices send back, and copies each one into a fixed 504-byte area of memory.

The size checks in that copy are wrong in both the IPv4 and IPv6 versions, so a message longer than 504 bytes spills past the area and overwrites nearby memory with data the attacker chose.

The Impact: Crash or Code Execution

The simple result is a crash. The boot hangs, and the machine fails to start.

Getting code to run is much harder and far less reliable. The advisory says that an attacker who knows the exact firmware build can plant a "counterfeit event" that causes the firmware to run the attacker's own code, so an exploit has to be built for a specific build. When code runs, it executes within the firmware, before Secure Boot and other boot-time checks have verified anything.

That timing is what makes the flaw serious. Code planted this way runs only once and does not survive a reboot by itself. That single run is still enough to install other code that does start on every boot.

Who Is Affected and Who Isn't

The bug sits in EDK II up to and including edk2-stable202608, the newest stable version dated August 21. The flawed copy loop has been in the code since a commit added in November 2010.

Affected Component

Status

EDK II (up to stable202608)

Vulnerable, no stable release contains the fix

Microsoft Project Mu

Fixed in tagged builds released October 26

Red Hat Enterprise Linux 8, 9, 10

Affected, not yet fixed

SUSE and Debian

Affected, not yet fixed

Intel commercial products

Not known to be affected

Arm product portfolio

Not directly applicable

PXE network boot is turned on by default in EDK II's standard build. The flaw does not affect home or office users who boot only from a local disk. It applies to organizations whose machines boot over a network, primarily servers and data center equipment.

Is There a Fix?

A fix has been merged into the EDK II source code. It rewrites the faulty copy so an oversized message is cut off at 504 bytes instead of spilling over, and it reached the main development branch on October 15.

No stable release of EDK II includes that fix yet. The newest stable release, edk2-stable202608, predates it, and the advisory still lists the patched version as "Not patched currently." Microsoft's Project Mu has already pulled the fix into its release branches and cut tagged builds on October 26.

Even with the fix public in source, a server operator has nothing to install until the maker of their firmware ships a BIOS or UEFI update built from it. Unlike Secure Boot bypasses such as BootHole and BlackLotus, this flaw can be fixed with a basic code fix and does not require certificate or key revocations.

What Defenders Should Do Right Now

Until that update arrives, the advisory lists no workaround. Because the flaw can only be reached during a network boot, operators who do not need PXE can disable it to reduce exposure. You should also watch boot-time network traffic and logs for signs of attempts.

The realistic attacker is an insider, or someone who has already gained a low-level foothold on the local network and wants to dig deeper. This is not a flaw that lets someone break in from the open internet.

The Accidental Disclosure

The flaw was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, and a coordinated disclosure had been planned for January 2027. That plan was overtaken on September 28, when a pull request to EDK II, signed off by an AMI engineer, publicly described the flaw by its CVE number and included the fix. Once the people who found it saw the post, TianoCore published its advisory on October 22, weeks before the planned date.

With the patch public, skilled attackers can study it to determine how the flaw is triggered and build working exploits. There is no sign the flaw has been used in an attack, and it was not in CISA's Known Exploited Vulnerabilities catalog as of October 27.

FAQ

What is CVE-2026-97631?

It is a buffer overflow in EDK II's PXE network boot code. If an attacker sends a specially crafted error message while a machine is booting from the network, they can crash the boot or, in specific conditions, run their own code before the operating system loads.

Does this affect my home PC?

Probably not. The flaw only matters if your machine boots over a network using PXE. If you boot from a local hard drive, you are not exposed.

Has this been exploited in the wild?

No. As of October 27, there is no sign the flaw has been used in an attack, and it is not in CISA's Known Exploited Vulnerabilities catalog.

How do I fix it?

The source code fix is available, but no stable EDK II release includes it yet. You need to wait for your hardware manufacturer to ship a BIOS or UEFI firmware update. In the meantime, disable PXE network boot if you do not need it.

Why is this flaw so old?

The flawed copy loop has been in the code since a commit added in November 2010. It was only discovered now because researchers started fuzzing the network-boot code after the PixieFail flaws in January 2024.

Source: The Hacker News
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067