A critical UEFI flaw in EDK II can let an attacker run code on a server before its operating system loads. EDK II is the open-source code that most computer makers build their firmware on. TianoCore, the project behind it, rated the bug 9.5 out of 10 in an advisory published Oct. 22.
The flaw is tracked as CVE-2026-97631 and sits in the driver that handles network booting.
The real exposure is at companies whose servers boot over the network, a routine setup in data centers. Laptops and office PCs that start from their own drive don’t use the vulnerable code. Developers have already written the fix. It still has to travel through firmware suppliers and hardware makers before it reaches most machines.
A single network packet during boot
Many servers don’t start from a local disk. They use PXE, the Preboot Execution Environment, to pull a startup image from a server on the local network. Data centers rely on it to set up new machines and reinstall old ones in bulk.
The advisory lays out how the bug works.
The PXE driver copies incoming ICMP error messages into a fixed 504-byte field. ICMP errors are the network’s standard “something went wrong” notices. The driver doesn’t check their length correctly, so an oversized message writes past the end of the field. Both the IPv4 and IPv6 versions of the driver have the flaw.
The simplest result is a crash that hangs the boot. The worse outcome takes more work. “An attacker who knows the target firmware build can plant a counterfeit event in the same packet,” the advisory says. That event makes the firmware run the attacker’s code during its DXE phase.
The timing is what makes this serious. According to TianoCore, the code runs “before Secure Boot or measured boot has verified or measured any OS component.” Secure Boot is the check that stops tampered operating systems from loading, so it offers no protection here.
The flawed copy loop is also old. The Hacker News traced it through the project’s history to a commit from November 2010.
Why a 9.5 score doesn’t mean mass hacking
The rating sounds alarming, but the conditions are narrow. An attacker has to send an ICMP error message straight to the target’s own IP address, and only while it is PXE booting. In the advisory’s words, “the exposure window is the duration of the PXE boot.” Running code, rather than causing a crash, also requires knowing the exact firmware build.
That’s why other scorers came in lower. Red Hat gives it a preliminary 8.8 on the older CVSS 3.1 scale.
Red Hat treats the attacker as someone on an adjacent network, meaning the local network, not the open internet. The Hacker News reports that SUSE scored it the same way. It also says Ars Technica described the realistic attacker as an insider or someone with a foothold on the network.
In practice, this is a tool for the second stage of an intrusion. Someone who has already broken into a data center network could use it to run code before the operating system exists. HD Moore of Dragos told The Hacker News that an attacker could “hijack program flow” at that point. The boot process then still has access to sensitive parts such as the TPM security chip, he said.
There’s no sign of attacks so far. The bug wasn’t in CISA’s catalog of known exploited vulnerabilities as of Oct. 27, The Hacker News reported. No researcher has reported seeing it used.
The catch is the boot order. IT-Connect points out that some machines list network boot ahead of their disk, or as a fallback. On those, the window opens on every reboot, not just during setup.
How an AMI engineer’s pull request broke the embargo
The bug was supposed to stay secret for longer. The Hacker News reports that the coordinated disclosure date was January 2027.
On Sept. 28, a public pull request appeared on the EDK II code repository. Its title named the CVE, and it carried a fix.
An engineer with an AMI email address signed off the commit. AMI is one of the main companies that turn EDK II into commercial firmware.
A project maintainer later explained what happened on the follow-up pull request. The “embargo was violated due to a mistake, resulting in the PR being created in the open,” the maintainer wrote.
Maintainers merged a revised fix with unit tests, pull request #13302, into EDK II’s main branch on Oct. 15. The advisory followed a week later. It still lists the patched version as “Not patched currently,” because no stable EDK II release includes the fix yet.
The advisory credits two researchers with finding the bug and proposing the fix. They are Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google. Neither the advisory nor the coverage we read says whether AI tools played a part.
Who is exposed, and who says they’re not
EDK II is shared code, so exposure depends on what each vendor did with it. IT-Connect lists AMI, Insyde and Phoenix among the firmware makers that build on EDK II. The same code also ships in OVMF, the firmware many virtual machines use.
Two chip companies say their own code is clear. Intel told Ars Technica that its reference code doesn’t include the affected EDK II functionality, according to The Hacker News. Intel added that none of its commercial products under security support are known to be affected. Arm said the flaw “is not directly applicable to Arm’s product portfolio.”
Neither statement covers the finished product. A server maker can add the PXE driver to firmware for Intel or Arm chips. The Hacker News reports that AMD, Phoenix, AMI, Microsoft, Amazon and TianoCore didn’t answer its questions before publication.
Linux distributions ship the code for virtual machines, and they haven’t caught up yet. Debian’s tracker lists its edk2 packages as vulnerable in every current release. The Hacker News reports that Red Hat lists the package in RHEL 8, 9 and 10 as affected and not yet fixed.
What server owners can do before firmware updates arrive
The advisory lists no workaround, so the practical steps come from the coverage. First, ask your server and firmware vendors whether your models ship the EDK II PXE driver. Ask, too, when a BIOS or UEFI update is due.
Next, turn off PXE boot on machines that don’t need it. Check that network boot isn’t first in the boot order or set as a fallback. Keep provisioning networks apart from general traffic, and watch boot-time network traffic and logs.
Anyone who isn’t running servers has nothing to do. Home and office machines that boot from their own drive aren’t in the attack path.
A busy month for low-level bugs
Security teams have already had a hard month. The PHP2Shell flaws forced emergency patching on web servers from Oct. 21. Our explainer on the “Black October” incidents covers how the separate problems overlapped.
The difference here is the patch path. A web host can install a PHP fix in an afternoon. A firmware fix moves from TianoCore to firmware suppliers to hardware makers. Then someone has to flash it onto each machine.
Microsoft’s Project Mu, a firmware codebase that grew out of EDK II, cut tagged builds with the fix on Oct. 26, The Hacker News reported. Next to watch for: a stable EDK II release with the patch, and the first BIOS updates from major server makers.
Disclosure: BreezyScroll uses Anthropic’s Claude to help draft articles.