Code-execution flaw in UEFI firmware threatens most servers on planet Earth

Critical flaw in EDK2 allows attackers to execute code early in the boot process.

Defenders across the world face the burden of responding to yet another botched code-execution vulnerability, this time in boot-time firmware used by most of the world's server vendors and data centers.

The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence. Last year, a representative of the UEFI Forum called EDK2 the "preeminent solution / implementation of the UEFI specifications."

Virtually all UEFI suppliers (sometimes still called IBVs or independent BIOS vendors), including AMI, Insyde, and Phoenix, use the reference code extensively. Project Mu, Microsoft's hardened EDK2 fork, used the code containing the vulnerable component as well.

The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code that runs before the operating system and firmware can implement defenses like Secure Boot, which establishes a chain of trust for all code, including the Trusted Platform Module (TPM), loaded during boot.

While final payloads delivered by CVE-2026-97631 have no persistence - meaning they run only once - they can give attackers a wide opening to install other payloads that also run each time early in the boot process.

The cat has left the bag

The parties that discovered CVE-2026-97631 - Alex Matrosov of Anthropic and Dan Holmes of Google - had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January.

AMI, a maker of motherboards and other hardware, published this pull request last month that detailed the vulnerability and included a code fix. Once the post came to the attention of the discovering parties, TianoCore Project members published a public advisory last week.

With publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and to build working exploits.

Further compounding the urgency, patching UEFI code vulnerabilities in millions of end devices sold and used by thousands of hardware makers and cloud providers is cumbersome and time-consuming.

Word of the vulnerability comes six days after another botched disclosure, this one involving a critical code-execution vulnerability in the PHP programming language.

1. The system is in PXE boot. That requires both that PXE boot is enabled for the system and that the attacker hits a window of seconds when the computer is watching its network adapter for PXE traffic.
2. The attacker can reach the computer with ICMP traffic in this window.

A great proportion of Internet facing resources are sitting behind some sort of front-end service, be that CloudFlare or various sorts of load balancers. If you ping the address for such a system, it's the front-end that answers those ICMP messages without delivering them to the back-end server.

The PHP thing was a vulnerability in a system that's intentionally exposed directly to Internet traffic and that's available 100% of the time, which made it far more exploitable.

The other thing that will really help with fixing this is that there need not be any extra service downtime. The fix is in the firmware, so patching needs only to set the firmware up to perform a capsule update on rebooted. The reboot itself can be delayed until one next happens normally.