CVE-2026-97631: 16-Year-Old UEFI Flaw Threatens Servers

CVE-2026-97631: A 16-year-old UEFI flaw (CVSS score of 9.5/10) enables pre-OS code execution. Exposed servers need firmware patches and checks.

A critical flaw, tracked as CVE-2026-97631 (CVSS score of 9.5), in the firmware that boots most of the world’s servers is now public, and the patch details came out months early.

The bug affects TianoCore EDK II, an open-source project used by hardware manufacturers and cloud providers to build UEFI firmware. UEFI is the software that starts a computer before the operating system loads. EDK II is widely used across the industry, including by major UEFI vendors such as AMI, Insyde and Phoenix. Even Microsoft’s more secure version, Project Mu, used the vulnerable component.

“EDK2 contains a vulnerability in BIOS where a user may cause “Out-of-bounds Write”, Classic Buffer Overflow, and “Incorrect Calculation of Buffer Size” by remote access. Successful exploitation of this vulnerability can lead to arbitrary code execution. It could also impact Confidentiality, Integrity, and Availability.” reads the advisory .

The flaw can corrupt memory in a component that handles ICMP messages, which devices use to report network errors. Attackers could exploit it to run code before the operating system starts and before security protections such as Secure Boot are fully active. Secure Boot checks that the software loaded during startup can be trusted, while the Trusted Platform Module (TPM) supports security functions such as hardware-based trust. Although the attacker’s code does not remain active after execution, it could help attackers install other malicious components that run early in the boot process.

The flaw is a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe). That driver lets servers, storage gear and other devices boot from code downloaded over a local network. While it does that, it listens for ICMP errors, and it never enforces the 504-byte limit on how much it copies.

“While a machine is PXE-booting over IPv4 or IPv6, an unauthenticated network attacker who can deliver ICMP error messages to it can corrupt DXE-phase memory and execute arbitrary code before the operating system loads, before Secure Boot or measured boot has verified or measured any OS component.” states the advisory .

A malicious insider, or a hacker with low-level access to the local network, can send an error message that spills code past the limit and corrupts the UEFI module running on the CPU.

The advisory is more precise. The driver keeps a receive request open for ICMP errors and copies each message into a fixed 504-byte field called Mode.IcmpError. In both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle) the bounds handling is wrong: a longer message still gets copied, and the destination pointer moves by the cumulative length and not the per-fragment length. So an oversized message writes attacker-controlled bytes past the field, and nothing earlier on the receive path limits its size.

The attack is simple. The attacker sends a direct message to the target’s IP address during the PXE boot process, even from a remote network. Sending invalid data can stop the boot process and cause a denial of service. If the attacker knows the target’s firmware version, they can create a fake event to run their own code at ring 0, the CPU’s highest privilege level. This also bypasses attestation, which uses cryptographic checks to prove that the hardware is trustworthy. As a result, the attack can help an attacker turn limited access into full control.

The attacker needs some control over the local network. This could be an insider or an external attacker who already has a foothold in the target network and is seeking to gain higher privileges. So far, there’s no evidence that this flaw can be exploited to gain initial access to a network from the outside.

The flaw affects some systems that start up over a network using EDK2-based firmware with PXE enabled. and small-office users, and anyone who boots only from a disk drive, aren’t affected.

Researchers planned to disclose the bug in January, but AMI published a fix last month, revealing details of the flaw. TianoCore then issued a public warning. Attackers can now study the fix to develop exploits, while updating firmware across many devices could take a long time.

It’s still unclear which devices are affected. Intel and Arm say their own products aren’t directly affected, but manufacturers may add vulnerable code. Several other companies hadn’t answered questions when the article was published.

Organizations should their system or firmware supplier and disable network boot where possible. They should also monitor logs for suspicious activity. TPM and Secure Boot remain useful protections, but they don’t stop this attack.

Follow me on Twitter: @securityaffairs and and Mastodon

( SecurityAffairs – hacking, CVE-2026-97631)