Skip to content
Bramble

Technology

Critical flaw in EDK2 UEFI firmware code could let attackers run code at boot

A 9.5-severity memory-corruption flaw (CVE-2026-97631) in the open source EDK2 firmware codebase could let an attacker with local network access run code before the operating system loads. Its details became public before the planned January disclosure.

2 outlets · 2L · 0C · 0R First reported Account updated
Image: Ars Technica
Image: Wired

1 / 2

The story, neutrally told

Left · 2A critical vulnerability rated 9.5 out of 10 has been found in TianoCore EDK II (EDK2), an open source codebase that hardware makers and cloud providers use to build the UEFI firmware that runs during boot-up. Left · 1Tracked as CVE-2026-97631, it is a memory-corruption flaw in an ICMP component that attackers can use to run malicious code before the operating system and firmware can apply defences such as Secure Boot. Left · 2It is a 16-year-old buffer overflow in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe), which lets devices boot from code downloaded over a local network. The driver does not enforce a 504-byte copy limit on ICMP error messages, so an oversized message overwrites adjacent data.

Left · 2The malicious message can be sent as a unicast from any network distance during the PXE boot sequence. An attacker can cause a denial of service by hanging the boot. If the attacker knows the target's firmware build, they can run code in ring 0, the CPU's most privileged level, and this bypasses attestation. Left · 1The payloads have no persistence, meaning they run only once, but they could give attackers an opening to install other payloads that run early in every boot. Left · 2Alex Matrosov of Anthropic and Dan Holmes of Google discovered the flaw and had arranged a coordinated disclosure for January. Last month AMI published a pull request that detailed the vulnerability and included a code fix. After the discoverers noticed it, TianoCore Project members published a public advisory last week.

Left · 2The reporting says the public patch code makes it trivial for advanced hackers to work out how the flaw is triggered and build exploits. It also says patching UEFI in millions of devices sold by thousands of vendors is cumbersome and slow. The report notes the disclosure came six days after another botched disclosure, of a PHP code-execution flaw. Left · 1Virtually all UEFI suppliers, including AMI, Insyde and Phoenix, use the EDK2 reference code extensively. Project Mu, Microsoft's hardened EDK2 fork, also used the vulnerable component. Left · 2HD Moore of Dragos said an attacker could hijack program flow while the boot process still has access to components such as the TPM. This could break disk encryption where an attacker has short-term network access, and would be easier in a theft. He said the flaw is likely a "forever" bug that will persist in end-of-support systems.

Left · 2The reporting lists limits on exploitation. An attacker needs some control of a local network, which likely confines exploitation to insiders or intruders such as nation-states or ransomware operators. There is no evidence yet that the flaw gives initial entry to a network. Jesse Michael of Eclypsium said exploits must be tuned to each target's model, version and configuration because memory addresses vary. Left · 1Michael added that, unlike Secure Boot bypasses such as BootHole, BlackLotus and Baton Drop, this flaw can be fixed with a basic code fix delivered as a BIOS/UEFI update, without key revocations or updates to OS and provisioning media. Left · 2Home and small-office users, and anyone who boots only from local disks, are not affected. The flaw applies to machines that boot over a network, where the firmware relies on EDK2 and uses PXE, which is on by default.

Left · 2Intel told the reporter that none of its commercial products currently under security support are known to be affected, because it does not include the affected EDK2 functionality in its reference code, though an OEM may integrate it. Arm said the CVE is "not directly applicable" to its portfolio. The articles note that public Intel and Arm firmware material still references EDK2, and they advise users of all servers to check whether they are affected. Left · 1The flaw follows earlier UEFI problems such as LogoFail and PixieFail, which was also a PXE boot flaw in EDK2. Fuzzing projects launched after PixieFail apparently did not find this one.

Every sentence links to the reporting it rests on. The pill in front of each says where its sources sit: Left, Centre or Right when one side supplies at least half of them, Mixed when they are evenly split. The number is how many outlets it cites.

Left2 outlets

Framing
Both pieces are one security report by Dan Goodin, first in Ars Technica and then republished by Wired. They lead on the scale of exposure ("most servers") and a botched disclosure, and then add caveats about who can actually exploit the flaw.
Emphasis
Breadth of EDK2 use across firmware vendors, the early leak through a public pull request, the difficulty of patching, expert quotes, and the limits on exploitation.
Leaves out or plays down
No right or centre coverage to compare. Neither piece reports a vendor patch rollout or any known exploitation.
Charged language
“botched code-execution vulnerability”“The Cat Has Left the Bag”“Yet Another Forever Day”
For example
“Defenders across the world face the burden of responding to yet another botched code-execution vulnerability” — Ars Technica
“Most Servers on the Planet Are Vulnerable to This Firmware Code-Execution Flaw” — Wired

Centre0 outlets

No centre outlet in our sources has covered this story yet.

Right0 outlets

No right outlet in our sources has covered this story yet.

Ask about this story

Loading…