Your server's security model has a load-bearing assumption buried in it: the code that runs first is trustworthy. Secure Boot, the TPM, disk encryption, remote attestation — all of it sits on top of firmware that executes before any of those defenses wake up. Yesterday's big story is about what happens when that assumption fails. CVE-2026-97631 is a 9.5-severity memory-corruption flaw in TianoCore EDK II, the open-source reference implementation of UEFI that virtually every firmware vendor — AMI, Insyde, Phoenix, and Microsoft's hardened Project Mu fork — builds on. It is a buffer overflow that has been sitting in the PXE boot driver for sixteen years. And it came to public attention the worst possible way: by accident, months before the coordinated disclosure date.
Here is what the bug actually is, why the disclosure timeline matters as much as the code, and what to do about machines you are responsible for.
The bug, precisely
The vulnerable component is the PXE Base Code driver — NetworkPkg/UefiPxeBcDxe — the part of EDK2 that lets servers, storage gear, and other devices boot from code downloaded over a local network. During a PXE boot, the driver keeps a receive request open for ICMP error messages and copies each received message into a fixed 504-byte field (Mode.IcmpError) in its private context structure. The copy loop's bounds handling is wrong in both the IPv4 and IPv6 handlers: for a message longer than 504 bytes it keeps copying, and it advances the destination pointer by the cumulative length rather than the per-fragment length. Nothing earlier on the receive path restricts the message length at all.
The result, per the official advisory (GHSA-99cj-7hg9-mp4m): an unauthenticated network attacker who can deliver ICMP error messages to a machine while it is PXE-booting — over IPv4 or IPv6, by simple unicast, from any network distance, as long as it arrives during the boot window — can corrupt DXE-phase memory. Best case for the attacker, worst case for you: a "counterfeit event" that executes attacker-controlled code on the CPU, in the UEFI firmware environment, at ring 0. Before the operating system loads. Before Secure Boot measures anything. Before the TPM attests to anything.
The flaw carries a CVSS v4 score of 9.5: network attack vector, low complexity, no privileges, no user interaction. It was discovered by Alex Matrosov of Anthropic and Dan Holmes of Google, and the CVE record was published on October 22.
Why "before your defenses" is the whole story
Pre-boot code execution is a different category of bad than the application-layer flaws I usually write about here. The payload itself has no persistence — it runs once. But code running at ring 0 in the firmware environment runs before the chain of trust exists, which means it can poison the chain: install something that does persist, interfere with the measurements the TPM will later make, or get at secrets the boot process still holds. HD Moore put the concrete scenario plainly to Ars Technica: an attacker with short-term network access could use this to break disk encryption by hijacking program flow while the endpoint's TPM is still reachable. Easier still in a theft scenario.
It also bypasses attestation — the cryptographic proof a machine gives to a remote server that its hardware and boot state are clean. If you can execute before the measurement, the measurement can be made to say whatever you want.
This is the same architectural lesson as LogoFail (image-parsing bugs in firmware logos), PixieFail (the previous PXE boot flaws in EDK2), PKFail (non-production test keys shipped in hundreds of device models for over a decade), BootHole, and BlackLotus. The industry keeps finding that the code running before its defenses is its least-reviewed code. After PixieFail, researchers ran multiple fuzzing campaigns against EDK2 specifically to flush out the rest of this class. Those campaigns missed this one. Sixteen years, in a fixed-size copy loop, in the preeminent UEFI implementation on Earth.
The disclosure was botched, and that changes your timeline
The discoverers had arranged for the vulnerability to stay under wraps until a coordinated disclosure scheduled for January. Then, last month, AMI — one of the independent BIOS vendors that builds on EDK2 — published a public pull request that described the vulnerability in detail and included the fix. Once that was noticed, TianoCore members published the public advisory last week. The cat, as Dan Goodin wrote in Ars Technica, has left the bag.
This is now the second botched security disclosure in a week, after the PHP2Shell mess. The mechanics of why it matters are identical and worth repeating: with public patch code, working out the trigger is not research, it is reading comprehension. Every advanced actor who cares now has both the vulnerability description and a reference fix to diff against. The window between "exploit trivially derivable" and "firmware patched across the fleet" is the exposure, and for UEFI that window is measured in months on a good day — firmware updates move slowly, through vendors, then through OEMs, then through whatever your org's maintenance process looks like. Moore's prediction is blunt: a "forever bug" that will live on in end-of-support systems permanently.
One more uncomfortable detail: the upstream EDK2 advisory currently lists no patched version. Vendors are integrating the fix themselves.
What this means if you run machines
The honest caveats first. This is not a drive-by internet worm. Exploitation requires the ability to deliver ICMP messages to the target during its PXE boot window — meaning some position on the local network, and a target that actually network-boots. That realistically scopes the threat to insiders, ransomware operators who already have low-level internal access and want to elevate, and nation-state actors doing supply-chain or data-center work. For a laptop that boots from its own disk with PXE disabled, the practical risk is far lower.
But if you run servers, storage, or anything that network-boots — and data centers do, at scale, by design — the checklist is short and unglamorous:
- Inventory what actually PXE-boots. The attack window only exists while a machine network-boots. If a machine does not need PXE, disabling it removes the exposure entirely — this is the single cheapest mitigation available.
- Treat boot-time network segments as trust boundaries. PXE traffic should live on isolated, controlled VLANs. If an attacker who lands in your flat office network can also reach machines during PXE boot, your segmentation is the vulnerability multiplier.
- Track vendor firmware updates by name, not by OS patch cycle. AMI, Insyde, Phoenix, and Microsoft Project Mu downstreams will ship fixes on their own schedules. OS-level package managers will not save you here; this lives below them. Ask your hardware vendors which EDK2 base they ship and when the ICMP fix lands.
- Watch EOL hardware. Anything out of support will not be patched. For those machines, mitigation is network-side: disable PXE, isolate the segment, or accept and document the residual risk.
The pattern worth keeping
Three stories this month rhyme, and the rhyme is the point. PHP2Shell: fix public before disclosure, scanners blind to the real exposure. The .NET out-of-band Brotli patch: the vulnerable decoder shipped everywhere, including in apps that bundle their own runtime. Now CVE-2026-97631: a 16-year-old copy loop in the firmware that runs before anything you call "security" starts. Different layers, same lesson — the trust chain is only as strong as its least-examined link, and the least-examined links are the ones everyone assumes someone else reviewed. Nobody reviewed the PXE driver's ICMP handler for sixteen years. Not because it was hidden, but because it was foundational, and foundational code has a way of becoming invisible.
Check your boot path. It is the part of your security model you are currently taking on faith.
Sources: TianoCore EDK II security advisory GHSA-99cj-7hg9-mp4m — https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m; CVE record CVE-2026-97631 (published 2026-10-22) — https://www.cve.org/CVERecord?id=CVE-2026-97631; Ars Technica, "Code-execution flaw in UEFI firmware affects most servers on planet Earth" (October 27, 2026) — https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-se
Top comments (0)