A 16-year-old bug in EDK2 lets attackers run code before Secure Boot even starts
Code-execution flaw in UEFI firmware threatens most servers on planet Earth
CVE-2026-97631 is a memory-corruption flaw in the ICMP parser of EDK2, the open source codebase behind UEFI firmware used by AMI, Insyde, Phoenix, Microsoft's Project Mu, and most server vendors. Rated 9.5 out of 10, the buffer overflow in the PXE boot driver lets anyone with local network access write past a 504-byte field and hijack the boot process in ring 0, before the TPM and Secure Boot defenses load. A patch is already public, making exploits easier to build.
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.
- FrasiertheLion
We recently wrote about moving away from OVMF (~1M lines of C) to very minimal and hyperspecific firmware (300 lines of assembly)[1] for our specific confidential VM machine targets, and the idea that "popular" does not automatically mean "secure". You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable. You can instead just write hyperspecific, small codebases and throw all the security practices at it - like LLMs (economical if it's small), fuzzing, formal methods etc.
- hn_submit
I've always been downright suspicious of the creation of UEFI. It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does. Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?
And unlike BIOS which is relatively small UEFI is "full-fat" almost the size of an operating system itself. It can even run its own applications.
The 1 million lines of C code comprising UEFI are riddled with bugs and this is just one of them. No doubt LLMs will be able to uncover a lot more of them.
- voidUpdate
So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
- rocqua
An interesting part of this is actually in defeating secure-boot or bitlocker. If a device is misconfigured for PXE boot with an otherwise locked down UEFI system, and strong secure boot. This could let you break the boot-chain and then disable secure-boot or extract keys from a TPM.
The main question here is how often devices you'd want to try this against have PXE boot enabled. I'm thinking of locked down laptops mostly. Either corporate laptops, or manufacturer locked-down devices (chromebooks, I think some microsoft surfaces).
- john_strinlai
>[...] had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January
we will hopefully soon see an end to this sort of naive optimism, especially when it's an ai-assisted/ai-found vulnerability.
- DamnInteresting
> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.
- NovemberPapa
How exploitable is this really? First, the machine has to do a PXE boot. In almost EVERY machine I have set up, it boots from fixed media first. Second, you have for force a machine reboot, and the machine has to be on a network you can reach.
Sure, there are lots of machines that PXE boot, but if it's on a public facing machine, why would you even configure it to PXE boot?
- AppAttestationz
On planet earth? Thank god the ai servers in space are safe!!