A memory-corruption flaw in the TianoCore EDK II open source codebase poses a severe risk to servers and other devices that boot from local networks, according to a public advisory issued last week by TianoCore Project members. The vulnerability, tracked as CVE-2026-97631, carries a severity rating of 9.5 out of 10. EDK2 is the reference code that virtually all UEFI suppliers, including AMI, Insyde, and Phoenix, use extensively, and a UEFI Forum representative last year called it the preeminent implementation of the UEFI specifications. Microsoft’s hardened EDK2 fork, Project Mu, also used the code containing the vulnerable component.

The flaw is a 16-year-old buffer overflow in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe), which lets servers, storage equipment, and other devices boot from code downloaded over a local network. During that process, the driver keeps a receive request open for ICMP error messages and copies each message into a fixed 504-byte field, Mode.IcmpError, of its private context structure. The bounds handling in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle) is incorrect, so an oversized message writes attacker-controlled bytes past the field. An attacker with low-level access to a local network can send such an error message to a target’s IP address during the PXE boot sequence.

Successful exploitation lets malicious code run before the operating system and before defenses such as Secure Boot and the Trusted Platform Module load, at ring 0, the CPU’s most privileged execution level. Payloads delivered this way have no persistence and run only once, but they can open the way for other payloads that execute early in every boot. An attacker can also cause a denial of service by hanging the boot sequence, and can plant a counterfeit event to run code when the target firmware build is known. The parties that discovered the flaw, Alex Matrosov of Anthropic and Dan Holmes of Google, had arranged a coordinated disclosure for January, but AMI published a pull request last month detailing the vulnerability and including a code fix, after which TianoCore members issued the advisory.

HD Moore, creator of Metasploit and chief research officer at Dragos, said the bug affects the chain of trust and the wider ecosystem, and that an attacker could use it to hijack program flow while the boot process still has access to sensitive components such as the TPM, potentially breaking disk encryption given short-term network access. Jesse Michael, a principal researcher at Eclypsium, said exploitation requires guessing specific addresses within the target system, so an exploit must be tuned for each model, version, and configuration. He said the flaw can be fixed with a basic code fix delivered through a BIOS/UEFI update, without the revocations and key-management work needed for Secure Boot bypasses. Moore said that given its ubiquity, the bug is likely a forever bug that will live on in end-of-support systems.

With patch code publicly available, advanced hackers can readily learn how to trigger the flaw and build working exploits, and patching UEFI code across millions of devices sold by thousands of hardware makers and cloud providers is cumbersome and time-consuming. The disclosure comes six days after another botched disclosure, this one involving a critical code-execution vulnerability in the PHP programming language. CVE-2026-97631 follows earlier UEFI flaws including LogoFail and PixieFail, the latter also stemming from faulty PXE boot code in EDK2; researchers had run multiple fuzzing projects to surface other critical flaws in the library, and those efforts appear not to have found this one.

The flaw does not affect home and small office users or anyone who boots only from disk drives, applying instead to organizations whose machines boot from local networks or conceivably from Internet-connected resources, and only where the firmware relies on EDK2 and uses PXE functionality, which is on by default. Intel said none of its commercial products currently under security support are known to be affected, that it does not include the affected EDK2 functionality in its reference code though an OEM board vendor or system manufacturer may integrate it, and advised customers to check with the appropriate party. There is no evidence yet that the vulnerability provides an initial entry point into a network, which likely limits exploitation to insiders or attackers such as nation-states or ransomware operators who already hold low-level access and are seeking to elevate privileges.

More hardware news from TechManNews.