lefteros_by SomniusX
EL ↗Say hello

LEFTEROS / PERSONAL NOTES

CVE-2026-97631: the UEFI flaw that hits servers before the OS starts

1 November 2026 / Lefteris Iliadis / SomniusX

A UEFI flaw that strikes before the OS even starts

I watched a short UFD Tech video saying that what happened with PHP might now happen to data centers: a 9.5 out of 10 flaw in server firmware, meant to go public in January 2027, came out early, and there's now a race to update servers before attackers get in.

The video is right on the main point. I went through the sources, though, and the picture has more nuance: this is serious, but it doesn't put every server at risk at every moment. The video also calls it a popular "brand" of BIOS. It isn't a brand. It's shared open source code, which is exactly why it spreads so far.

What was found

The flaw is CVE-2026-97631, rated 9.5 out of 10 (CVSS 4.0), and described in the official TianoCore advisory of 22 October. It lives in EDK II, the open source code vendors use to build UEFI firmware, the first thing that runs when a machine powers on. AMI, Insyde and Phoenix build on it, and so does Microsoft's Project Mu.

The problem is in the driver for PXE, booting over the network. While a machine PXE-boots, it listens for ICMP error messages and copies them into a fixed 504-byte field. The size handling is wrong in both IPv4 and IPv6, so a longer message writes past the field, with content the attacker chooses.

According to the advisory, that leads to one of two outcomes:

  • A hung boot, so the machine never reaches provisioning or recovery.
  • Code execution at the highest privilege level, if the attacker knows the target's exact firmware build.

The second is the scary one, because it happens before Secure Boot or measured boot has checked anything of the OS. No antivirus or EDR is running yet. The payload itself does not persist and runs only once, but as Ars Technica reports it gives attackers an opening to install something else that runs early on every boot. HD Moore of Dragos said this could be used to break disk encryption in cases where an attacker has short-term network access.

How it came out early

Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) found the flaw, and disclosure was planned for January 2027 to give vendors time. In September, however, a public code change signed off by an AMI engineer named the CVE and contained the fix. From then on the secret was gone:

Date What happened
September Public code change from AMI
15 October Fix merged into EDK II
22 October TianoCore advisory
26 October Project Mu ships builds with the fix
January 2027 The originally planned disclosure

This comes days after PHP2Shell, where details also came out ahead of schedule.

Who it really affects

The Ars Technica headline shown in the video talks about most servers on the planet. That describes how widespread the code is, not how many machines can be attacked today. The limits are real:

  • A PXE boot must be in progress. Machines that boot only from local storage aren't affected. The window lasts as long as the boot does.
  • It needs tailoring. An exploit has to match the target's firmware and configuration.
  • It isn't clear which systems are affected. Intel says it knows of no affected product among its supported commercial ones, though device makers may have added the code. Arm says it doesn't directly apply to its products.

There's also a real disagreement. The TianoCore advisory says the message can come "from any network distance", while Red Hat and SUSE rate it as exploitable from an adjacent network. I'd plan for the worse of the two.

The most exposed are those who provision or recover machines over the network: data centers, hosting, large corporate networks. In practice, the most realistic risk is someone already inside the network who wants to hide beneath the OS.

The sources I read report no active exploitation, and on 27 October the flaw wasn't on CISA's known-exploited list. That can change, since the fix is public and shows where to look.

Why updates will take time

The fix itself is simple: Jesse Michael of Eclypsium says it's a basic code change, with no key revocation needed. The hard part is the route. It has to go from EDK II to firmware suppliers, then to hardware makers, and finally to whoever flashes each machine, usually with a reboot. As of 28 October no stable EDK II release had the fix, and Red Hat, SUSE and Debian listed their packages as affected and unfixed. Some older servers may never get an update.

What to do now

  1. Turn off PXE where you don't need it. This is the most important step and costs almost nothing. Remove network entries from the boot order in the BIOS. On Linux, efibootmgr -v shows what's there.
  2. Where you need it, isolate it. Keep provisioning on its own VLAN, with strict rules on who can reach it. This is my own advice; the advisory offers no workaround.
  3. Ask your hardware vendor. Dell, HPE, Lenovo, Supermicro or whoever you use, and watch their bulletins. Don't assume you're affected or that you aren't.
  4. Don't forget virtual machines. Distribution edk2 packages are the firmware UEFI VMs run on, so update them as soon as fixes land, especially if they network-boot.
  5. List what boots from the network. When firmware arrives, you'll know where to start.

If you have a VPS or a hosted site, there's nothing for you to do yourself: firmware is the provider's job. All you can do is ask them.

Sources