Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of a dark server hall at night: rows of rack cabinets receding into shadow, one cabinet glowing amber at its base with a thin stream of light spilling across the floor toward a neighbouring cabinet

UEFI PXE Flaw CVE-2026-97631: Servers at Risk Before Secure Boot

by

UEFI PXE Flaw CVE-2026-97631: Servers at Risk Before Secure Boot

In brief

  • A 16-year-old buffer overflow in EDK II’s PXE driver lets a local-network attacker run code before Secure Boot — and no firmware update with the fix exists yet.
  • The flaw, CVE-2026-97631, scores 9.5 out of 10 and sits in the firmware that boots most of the world’s servers — but it only fires while a machine is network booting, so home users who boot from a local disk are not affected.
  • TianoCore published its advisory on October 22, 2026, weeks ahead of a planned January 2027 disclosure, after a public pull request exposed the bug in September.
  • The fix exists in source code but in no stable release and no vendor firmware update, so the immediate defense is to switch off PXE network boot on machines that do not need it and press vendors for a shipping date.

Last verified: October 29, 2026.

What happened

On October 22, 2026, TianoCore, the project behind EDK II, published a security advisory for a critical flaw in the open-source code that most hardware makers use to build UEFI firmware. UEFI is the firmware that runs first when a computer is switched on, before the operating system loads. EDK II is the reference implementation that independent firmware vendors AMI, Insyde and Phoenix build on, and Microsoft’s hardened Project Mu fork carried the same vulnerable component.

The flaw is tracked as CVE-2026-97631 and carries a CVSS v4 score of 9.5 out of 10. It is a buffer overflow in the PXE Base Code driver (UefiPxeBcDxe) inside EDK II’s NetworkPkg — the piece of firmware that lets a server, storage box or workstation pull its boot image over the network instead of from a local disk. The faulty copy loop has been in the code since a commit added in November 2010, which makes this a 16-year-old bug hiding in one of the most widely deployed codebases in computing.

The flaw was found by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, according to the advisory’s 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 researchers saw the post, TianoCore published its advisory weeks early. With the patch now public, skilled attackers can study it to work out how the flaw is triggered and build working exploits — which is why the disclosure timeline matters as much as the bug itself.

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. That is a statement about what is known today, not a reason to wait: the window between public patch and vendor firmware update is exactly when attackers do their homework.

How the flaw works

During a PXE boot, the driver keeps a listener open for ICMP error messages — the small status messages network devices send back — and copies each one into a fixed 504-byte field of memory. According to TianoCore’s advisory, the copy loop gets its bounds wrong in both the IPv4 and IPv6 handlers: the destination pointer advances by the cumulative rather than per-fragment length, and nothing earlier in the receive path caps the size. Attacker-controlled bytes land past the end of the buffer.

The trigger is a single crafted ICMP error message aimed at the machine’s IP address while it is network booting. No password and no existing access to the machine are needed, but the attacker does need to reach the machine 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 — in practice, an insider, or someone who has already gained a low-level foothold on the local network and wants to dig deeper.

The simplest 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 in the DXE phase — ring 0, long before the operating system loads and before Secure Boot or measured boot has verified or measured any OS component. 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. As HD Moore, creator of Metasploit and chief research officer at Dragos, told Ars Technica, an attacker who hijacks program flow at this point 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).”

Who is actually at risk — and who is not

The most important scope limit in this story is also the most commonly dropped. 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 datacenter equipment. PXE network boot is turned on by default in EDK II’s standard build, so in an office that usually means servers, virtualization hosts, and any PC that is imaged over the network.

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. AMD, Phoenix Technologies, AMI, Microsoft and Amazon did not answer questions before publication, so the status of their products remains unclear.

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. If you run virtual machines on a public cloud, the host firmware belongs to the cloud provider, not to you — your exposure there is the provider’s problem to fix, and worth asking them about. Your own exposure is the hardware you own: colo racks, on-premises virtualization hosts, lab machines, and the PXE provisioning network your platform team built years ago and nobody has inventoried since.

Why there is no patch yet

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. But no stable release of EDK II includes that fix yet — the newest, edk2-stable202608, dated August 21, 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 the bottleneck, and it is the same supply-chain shape as every firmware flaw: the reference code is fixed in days, the vendor builds take weeks to months, and the installed base updates slower still.

There is one piece of genuinely good news. 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, according to Jesse Michael, a principal researcher at the firmware security firm Eclypsium. When vendor updates do arrive, installing them should be straightforward — no key ceremony, no revocation list, no bricked-boot risk from a certificate change. The hard part is the wait, not the fix.

What to do now

The advisory lists no workaround, but the flaw’s own limits point to the mitigations. Because it can only be reached during a network boot, operators who do not need PXE can disable it to reduce exposure. That is the single highest-value action available today, and it costs nothing.

First, in the firmware setup (or the server’s remote management console), check whether network boot or PXE is turned on and listed in the boot order. Turn it off on every machine that boots from its own disk and never uses network imaging. Second, ask your server and PC vendors when a BIOS update with the fix for CVE-2026-97631 will ship, and plan to install it the day it lands — the update will be a routine firmware flash, not a key rotation. Third, watch boot-time network traffic and logs for signs of attempts: an oversized ICMP error aimed at a machine mid-boot is not normal traffic, and it is detectable. Fourth, inventory which machines you actually own firmware for. If you cannot list your PXE-booting machines and name an owner for each, that inventory is the work — the flaw punishes exactly the environments where nobody knows what boots from the network.

For cloud workloads, confirm with your provider that host firmware is covered by their patching, and check whether any of your own images or bare-metal instances carry EDK II-based firmware you are responsible for. And keep an eye on CISA’s Known Exploited Vulnerabilities catalog: the flaw is not listed as of October 27, but that status can change, and a listing would raise the urgency for every unpatched PXE-booting machine at once.

Why this bug matters beyond itself

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 Technica reported that fuzzing projects started after PixieFail to find more bugs in the code did not catch this one — a 16-year-old overflow survived a dedicated hunt in the exact component that had just been embarrassed.

That is the deeper lesson. Firmware sits below every defense the industry talks about — below the operating system, below endpoint protection, below disk encryption — and its supply chain runs from an open-source reference project through three independent BIOS vendors and dozens of system makers to your rack. A bug can live in that chain for sixteen years, survive a targeted fuzzing effort, and reach the public only because a pull request leaked it early. The fix will be easy. Knowing which of your machines need it, and closing the network-boot window until it arrives, is the actual work.

Related reading

Sources

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment