Firmware is the patch gap nobody owns, and the new UEFI bug proves it

Your EDR is excellent, your hypervisor is current, your container images were rebuilt last night. So who patches the code that runs before any of it exists?

That is the uncomfortable question behind CVE-2026-97631, a critical flaw in TianoCore EDK II, the open-source reference codebase that most UEFI firmware vendors use. Per the summaries of Ars Technica's reporting, it sits in an ICMP component, in the network-boot path, and is rated 9.5 out of 10. It lets an attacker execute code during boot, before protections like Secure Boot and the TPM can establish a chain of trust.

Some details matter. The payloads reportedly don't persist on their own, but they can install other code that runs on every later boot. The flaw also went public before a disclosure that was planned for January, according to a FourWeekMBA recap of Ars. And Eclypsium's Jesse Michael told Ars that the fix means deploying a BIOS/UEFI update.

"Most servers on Earth" is a headline, not a measurement

Some restraint first. The headline says the flaw threatens most servers on the planet. As Tech Insider points out, the coverage says the reference code is used by most of the world's server vendors, but it gives no count of affected machines and no percentage. Shared code is not the same as shared exposure. Vendors' builds and configurations probably differ, and whether a given box is reachable through that network-boot path likely depends on setup.

We think that nuance cuts both ways. It means you shouldn't panic-reboot your whole fleet tonight. It also means you can't know your exposure from a headline, and we suspect many organizations can't answer it from their own records either. That is the real story.

The bug is new; the broken pipeline is old

Look at how a firmware fix travels. In Ars's 2024 coverage of an earlier wave of UEFI bugs, the chain was laid out plainly: firmware makers push updates to their customers, and those customers make patches available to their own customers, who are usually the end users. Every hop is a separate company, and in our view nobody owns the whole path.

Compare that with a library bug. When a Brotli flaw surfaced recently, Google and Node.js shipped fixes on October 21 and Microsoft followed with an emergency.NET update over the weekend, according to TechRadar. Even that was messy: bundled copies mean updating Google's library alone doesn't protect every app. But the fix at least travels through channels most teams already know how to run, like package updates and redeploys. Firmware offers no such routine. You have to learn which vendor's image you run, wait for the OEM to repackage it, schedule a maintenance window, and flash machines that people would rather not reboot.

Then there is the layer where defenders would normally catch a problem. Pre-boot code runs below the operating system, so the tools most teams rely on may have little visibility into it. Firmware has also had a bad few months. In September, Cybernews reported a Secure Boot bypass via the UEFI Shell that AMI, Gigabyte, Insyde and Cisco acknowledged, with many more vendors likely affected. Two incidents in two months don't make a trend on their own, but they do point to a weak spot.

Treat firmware like a product with an owner

Our verdict is simple: if firmware has no owner on your team, you have already decided to patch it late. The fix is mostly process, not tooling.

• Inventory it. Know which firmware version and which vendor build sits on every server. Without that, "are we affected?" takes days instead of minutes.
• Name an owner. Someone should track vendor advisories and have the authority to schedule maintenance windows, the way a team owns its OS patch cadence.
• Shrink the reachable surface. If you don't need network boot on a machine, turning it off may be a cheap mitigation. We can't promise it covers every configuration, so check what your vendor says.
• Rehearse flashing. A BIOS update that has never been practiced on your hardware is a gamble when it matters.

Vendors have homework too. A reference codebase shared across the industry should come with a shared, predictable way to get fixes to customers. Until that exists, the burden falls on admins, which isn't fair but is the reality.

The lesson of this CVE won't be remembered for its score. The question to ask is how long it would take your organization to know which of its machines are exposed. If the honest answer is "we'd have to find out," firmware is your patch gap, and nobody else is going to close it.