Most security patches land somewhere you can reach with a package manager. CVE-2026-97631 sits much lower: in the UEFI firmware that runs before the operating system even starts, and in the open source code almost every server vendor builds that firmware from.
What’s vulnerable
The flaw lives in TianoCore EDK II, the reference implementation of the UEFI specification. Firmware vendors such as AMI, Insyde, and Phoenix use EDK II code extensively, and Microsoft’s hardened fork, Project Mu, also included the vulnerable component, according to Ars Technica.
The bug is in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe), which lets machines boot from images served over the local network. While PXE boot runs, the driver listens for ICMP error messages and copies each one into a fixed 504-byte field. Per the official advisory, the copy loop in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle) mishandles bounds: it keeps copying messages longer than 504 bytes and advances the destination pointer by the cumulative rather than per-fragment length. An oversized message writes attacker-controlled bytes past the buffer.
The bug is about 16 years old, and it carries a severity rating of 9.5 out of 10.
Why firmware bugs are different
Code that runs this early runs in ring 0, before the OS and before defenses like Secure Boot have set up their chain of trust. That position can be used to tamper with what loads next or to reach sensitive components such as the TPM. HD Moore of Dragos told Ars this could be used to break disk encryption when an attacker has short-term network access, or more easily in a theft scenario.
The payload itself doesn’t persist, but it gives an attacker an opening to install other code that does run on every boot.
A disclosure that broke early
The issue was found by Alex Matrosov of Anthropic and Dan Holmes of Google, with coordinated disclosure planned for January. A public pull request containing the fix appeared early, and the TianoCore project then published an advisory. With patch code public, building an exploit gets much easier, while rolling firmware updates out to millions of devices is slow.
Real-world limits
This is serious, but it’s not an internet-wide remote takeover:
- Network boot is required. Machines that only boot from local disks, including typical home and small-office PCs, aren’t exposed.
- Timing and reach matter. The attacker has to deliver a crafted ICMP message to the target during the PXE boot window.
- Exploits are target-specific. Eclypsium’s Jesse Michael told Ars that an attacker needs to know specific memory addresses, so exploits must be tuned per model, version, and configuration.
- No sign it’s an initial entry point. It’s most useful to someone already inside a network, such as an insider, a ransomware crew, or a nation-state actor.
The good news is the fix is a plain code change delivered as a BIOS/UEFI update, without the key revocations and DBX updates that Secure Boot bypasses like BlackLotus required.
What to do now
- Ask your server and firmware vendors whether their UEFI builds include the vulnerable EDK II PXE code, and schedule their updates.
- Disable PXE/network boot on machines that don’t need it, at least until patched.
- Segment provisioning networks so only trusted infrastructure can reach machines while they network-boot.
- Keep Secure Boot and TPM enabled anyway; they don’t stop this bug, but they still raise the bar elsewhere.
- Watch logs for unusual ICMP traffic on provisioning VLANs and for unexpected reboots into PXE.
