Code-execution flaw in UEFI firmware affects most servers

A critical code-execution vulnerability in TianoCore EDK II, the open-source codebase behind much UEFI boot firmware, went public ahead of a coordinated disclosure that had been scheduled for January. Tracked as CVE-2026-97631 and rated 9.5 out of 10, it affects boot firmware used by most of the world's server vendors and data centers, though only organizations whose machines boot from a network are exposed.

Memory corruption during PXE boot

CVE-2026-97631 is a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe), which lets servers, storage equipment, and other devices boot using code downloaded from a local network. During that pre-execution environment boot, the driver keeps a receive request open for ICMP error messages and copies each message into a fixed 504-byte Mode.IcmpError field. The copy handling is incorrect in both the IPv4 and IPv6 handlers, so an oversized message can write attacker-controlled bytes past the field. A malicious insider or a hacker with low-level access to a local network can send such an error message during the PXE boot sequence, corrupting the UEFI module running on the CPU. The code runs in ring 0, before the operating system loads and before firmware enforces defenses such as Secure Boot and the chain of trust it establishes for all code loaded during boot, including the TPM.

Disclosure came early

The vulnerability was discovered by Alex Matrosov of Anthropic and Dan Holmes of Google, who had arranged for it to stay under wraps until a coordinated disclosure scheduled for January. AMI published a pull request last month that detailed the vulnerability and included a code fix, and TianoCore Project members published a public advisory last week after the post came to the discoverers' attention. With patch code publicly available, it will be trivial for advanced hackers to learn how the flaw is triggered and build working exploits. The payloads the flaw delivers have no persistence, meaning they run only once, but they can open the way for other payloads that also run each time early in the boot process.

Who is affected

Virtually all UEFI suppliers, including AMI, Insyde, and Phoenix, use the EDK2 reference code extensively, and Project Mu, Microsoft's hardened EDK2 fork, also used code containing the vulnerable component. The flaw does not affect home and small office users, or anyone who boots solely from disk drives. It applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources, and even then only when the firmware relies on EDK2 and uses PXE functionality, which is on by default. Some level of control over a local network is a prerequisite, which likely limits exploitation to insiders or to attackers such as nation-states or ransomware operators who manage to gain low-level access and are looking to elevate system rights. There is no evidence yet that CVE-2026-97631 provides an initial entry point into a network. Jesse Michael, a principal researcher at firmware security firm Eclypsium, said an attacker has to guess specific addresses within the target system, so an exploit has to be tuned for each model, version, and configuration rather than working against a diverse range of devices. Intel said 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, while Arm said the issue is not directly applicable to its product portfolio. Publicly available Intel reference code, however, makes reference to EDK2, and firmware Arm makes available also borrows heavily from it, so while it is possible some platforms are free of EDK2 code, it is prudent for users of all servers to investigate whether CVE-2026-97631 affects them. AMD, Phoenix Technologies, AMI, Microsoft, and Amazon did not answer questions before publication.

What defenders can do

Those affected should check with the maker of the firmware used to boot their systems and ask for guidance. They should consider turning off network boot capabilities at least temporarily if possible. Firmware configurations should enable security features such as TPM and Secure Boot whenever possible, although those defenses do not protect against this particular threat. It is also a good idea to monitor logs for signs of exploitation attempts. HD Moore, creator of Metasploit and chief research officer at Dragos, said an attacker intent on compromising a nearby endpoint or server, with short-term network access, could use the bug to hijack program flow while the boot process still has access to sensitive components such as the TPM, potentially breaking disk encryption.

Sources: Ars Technica