A critical 16-year-old flaw in EDK II , the open-source code that most hardware makers use to build UEFI firmware, can allow an attacker to run code on a machine before its operating system loads, but only while the machine is booting over the network.
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 such 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.
An attacker needs no password and no existing access to the machine, but does need to reach it over the network during the short window when it is booting this way.
Red Hat and SUSE, which both ship the affected code, rated the flaw as one an attacker exploits from an adjacent network position rather than across the open internet.
TianoCore, the project behind EDK II, published an advisory on October 22 and rated the flaw, tracked as CVE-2026-97631 , 9.5 out of 10. A code fix exists, but no stable release of EDK II contains it yet, and the advisory still lists no patched version, so most users have nothing to install today.
What the Flaw Lets an Attacker Do
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.
As part of this, the PXE driver listens for ICMP error messages and the 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 of the code, so a message longer than 504 bytes spills past the area and overwrites nearby memory with data the attacker chose.
To set this off, an attacker only has to send one crafted error message to the machine's address while it is in the middle of a network boot. No password or existing access to the machine is needed.
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.
The bug sits in EDK II up to and including edk2-stable202608 , the newest stable version, dated August 21. EDK II is the reference code that nearly every UEFI firmware vendor builds on, including the independent BIOS makers AMI, Insyde, and Phoenix, as well as Microsoft's hardened fork, Project Mu.
The flawed copy loop has been in the code since a commit added in November 2010 , The Hacker News found by tracing the project's history.
PXE network boot is turned on by default in EDK II's standard build. The flaw does not affect 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.
How many shipping products carry the vulnerable code is not known. Intel told Ars Technica that none of its "commercial products currently under security support" are known to be affected, and that it "does not include the affected EDK2 functionality in its reference code," though an OEM board vendor or system maker could add it.
Arm said the flaw "is not directly applicable to Arm's product portfolio." Both companies' own firmware draws on EDK II.
Linux distributions also ship the code. Red Hat lists its edk2 package in Red Hat Enterprise Linux 8, 9, and 10 as affected and not yet fixed, and SUSE and Debian mark their equivalent packages the same way.
AMD, Phoenix Technologies, AMI, Microsoft, and Amazon did not answer the tech news site's questions before publication, and TianoCore did not respond either, so the status of their products remains unclear.
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 Hacker News checked the project's release tags on October 28 and found the newest, 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. That step is at least straightforward, Jesse Michael, a principal researcher at the firmware security firm Eclypsium, told Ars Technica: unlike Secure Boot bypasses such as BootHole and BlackLotus, the flaw "can be fixed with a basic code fix" and does not require certificate or key revocations.
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. Ars also advised watching boot-time network traffic and logs for signs of attempts.
The flaw was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, the advisory credits. 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, Ars noted that 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. It was not in CISA's Known Exploited Vulnerabilities catalog as of its October 27 update, and no researcher has reported seeing it exploited.
The flaw is also not, on its own, a way into a network, Ars Technica reported after putting questions to several firmware researchers. 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.
"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," said HD Moore, the creator of Metasploit and chief research officer at the security firm Dragos, in to Ars Technica.
"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)."
It is not the first serious flaw in EDK II's network-boot code. In January 2024, researchers disclosed PixieFail , a set of nine flaws in the same part of EDK II, also reachable during PXE boot. Ars reported that fuzzing projects started after PixieFail to find more bugs in the code did not catch this one.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
