Security teams got another unplanned disclosure this week, and this one sits underneath the operating system rather than inside it.
CVE-2026-97631 is a buffer overflow in the TianoCore EDK II codebase, the open-source reference implementation that AMI, Insyde, Phoenix and Microsoft's hardened Project Mu fork all build UEFI firmware from. The vulnerable component is the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe), which lets a machine boot from code fetched over a local network. During that boot the driver keeps a receive request open for ICMP error messages and copies each one into a fixed 504-byte field. The bounds handling is wrong in both the IPv4 and IPv6 handlers, so an oversized message writes attacker-controlled bytes past the field and corrupts the module running on the CPU.
The result is code execution in ring 0 inside the firmware environment, before Secure Boot or the TPM can establish a chain of trust. Payloads delivered this way do not persist on their own, but they run at the one moment when an attacker can plant something that does.
The preconditions matter. An attacker needs some control of a local network, has to send the packet during the PXE boot sequence, and has to tune addresses to the target's firmware build. As Jesse Michael of Eclypsium told Ars Technica, this is not an exploit you throw at any target: model, version and configuration change the addresses. HD Moore, now chief research officer at Dragos, expects it to become a forever bug living on in end-of-support systems.
The disclosure is part of the story. Alex Matrosov of Anthropic and Dan Holmes of Google found the flaw, and a coordinated release was scheduled for January. AMI published a pull request last month that detailed the vulnerability along with a fix; TianoCore followed with a public advisory last week. With patch code in the open, working exploits are now a matter of effort rather than insight.
Vendor responses are thin. Intel said none of its commercially supported products are known to be affected and that it does not ship the affected EDK2 function in its reference code, though an OEM may integrate it. Arm said the flaw is not directly applicable to its portfolio. AMD, Phoenix, AMI, Microsoft and Amazon had not answered Ars' questions when the story ran. Both Intel and Arm publish code that borrows heavily from EDK2, and TianoCore has documented that reliance.
The practical advice is unglamorous: ask the firmware vendor for an update, and turn off network boot at least temporarily where it is not needed. Secure Boot and the TPM do not help here, because the attack runs before they load. Jesse Michael notes one consolation — this class of bug is fixed with an ordinary BIOS update, without the key revocations and media rebuilds that a Secure Boot bypass demands.
It joins a crowded shelf: PixieFail was a similar PXE flaw in EDK2, and LogoFail, PKFail, BootHole and BlackLotus all traded on the same early-boot window. Fuzzing campaigns launched after PixieFail did not surface this one. The advisory also lands six days after a critical code-execution flaw in PHP became public, which is its own argument about how firmware and library disclosures keep escaping their embargoes.
