9.5-Severity UEFI Firmware Flaw Threatens World's Servers

A memory-corruption flaw rated 9.5 out of 10 for severity sits inside the boot-time firmware used by most server vendors and data centers on Earth, according to a report from Ars Technica. The vulnerability, tracked as CVE-2026-97631, lives in TianoCore EDK II, the open source codebase that hardware makers use to build UEFI firmware — the code that runs before an operating system loads.

What does CVE-2026-97631 actually do?

The flaw is a buffer overflow in an ICMP component of the EDK2 network stack, Ars Technica reports. Attackers who exploit it can execute malicious code early in the boot sequence — before protections like Secure Boot and the Trusted Platform Module (TPM) can establish a chain of trust. The payload itself does not persist; it runs once. But researchers say that single run can be enough to plant other code that reloads every time the machine boots.

HD Moore, creator of Metasploit and chief research officer at security firm Dragos, told Ars Technica the bug is notable because of where it lands in the boot process.

"An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint's TPM. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario)."

Why is a 16-year-old bug surfacing now?

The underlying flaw is 16 years old, according to Ars Technica's reporting. It sat unnoticed in reference code that nearly every independent BIOS vendor — including AMI, Insyde, and Phoenix — builds on. Microsoft's hardened EDK2 fork, Project Mu, used the same vulnerable component. A representative of the UEFI Forum last year called EDK2 the "preeminent solution / implementation of the UEFI specifications," which is why a single flaw there ripples across the entire server supply chain rather than staying contained to one brand.

How did the disclosure leak before it was supposed to?

The vulnerability was found by Alex Matrosov of Anthropic and Dan Holmes of Google, who arranged a coordinated disclosure for January, Ars Technica reports. That plan broke down last month when AMI published a pull request containing the vulnerability's details and a code fix. Once the discovering researchers noticed the post, the TianoCore Project published a public advisory the following week — months ahead of schedule.

That timeline matters because the disclosure now runs backward from how coordinated vulnerability releases are supposed to work: patch code is public, but most affected hardware isn't patched yet.

Timeline

• 16 years ago: The buffer overflow is introduced into EDK2's ICMP parser, per Ars Technica.
• Scheduled for January 2027: Matrosov and Holmes arrange coordinated disclosure with vendors.
• September 2026: AMI publishes a pull request detailing the flaw and a fix.
• Mid-October 2026: TianoCore Project issues a public advisory after researchers spot the leak.
• Six days before this report: A separate botched disclosure hits a critical PHP code-execution vulnerability, per Ars Technica.

Which servers and devices are exposed?

Because EDK2 underlies firmware from AMI, Insyde, Phoenix, and Microsoft's Project Mu, the exposure spans most server hardware sold to data centers and cloud providers, Ars Technica reports. The piece does not name specific cloud vendors or quantify affected device counts beyond characterizing the reach as "most servers on planet Earth" — a framing tied to how widely EDK2's reference code is reused rather than to a single counted inventory.

What can administrators do right now?

Patch code is already public following AMI's pull request and the TianoCore advisory, which means working exploits could follow quickly, Ars Technica notes. The harder problem is deployment: patching UEFI firmware across millions of devices from thousands of hardware makers and cloud providers is, in the outlet's words, "cumbersome and time-consuming." Unlike an operating-system patch pushed overnight, firmware updates often require vendor-specific images, reboot windows, and in some cases physical access — all variables that slow response even after a fix exists.

For organizations running on-premises servers, the near-term step is checking with hardware vendors for EDK2-based firmware updates referencing CVE-2026-97631 and prioritizing systems with network-exposed management interfaces, since the flaw is reachable over ICMP. For cloud customers, the exposure runs through the provider's own patch cycle rather than anything an end user controls directly.

The full technical writeup, including the AMI pull request history and the TianoCore advisory, is detailed in Ars Technica's report.