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.
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. Ars TechnicaLC “The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence.” Read at Ars Technica ↗ WiredLC “The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence.” Read at Wired ↗ 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. Ars TechnicaLC “The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code” Read at Ars Technica ↗ 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. Ars TechnicaLC “CVE-2026-97631 is a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe)” Read at Ars Technica ↗ WiredLC “Because the driver doesn’t enforce a memory copy limit of 504 bytes, overwriting adjacent data” Read at Wired ↗
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. Ars TechnicaLC “The malicious error can be delivered through a simple unicast sent from any network distance to a target device’s IP address, as long as it’s sent during the PXE boot sequence.” Read at Ars Technica ↗ WiredLC “The code runs in ring 0, a CPU’s most privileged execution level.” Read at Wired ↗ 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. Ars TechnicaLC “While final payloads delivered by CVE-2026-97631 have no persistence—meaning they run only once—they can give attackers a wide opening” Read at Ars Technica ↗ 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. Ars TechnicaLC “had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January.” Read at Ars Technica ↗ WiredLC “TianoCore Project members published a public advisory last week.” Read at Wired ↗
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. Ars TechnicaLC “With publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and to build working exploits.” Read at Ars Technica ↗ WiredLC “Word of the vulnerability comes six days after another botched disclosure” Read at Wired ↗ 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. Ars TechnicaLC “Virtually all UEFI suppliers (sometimes still called IBVs or independent BIOS vendors), including AMI, Insyde, and Phoenix, use the reference code extensively.” Read at Ars Technica ↗ 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. Ars TechnicaLC “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” Read at Ars Technica ↗ WiredLC “Moore said it’s likely a “forever” bug that will live on in end-of-support systems.” Read at Wired ↗
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. Ars TechnicaLC “There’s no evidence yet that CVE-2026-97631 provides an initial entry point into a network.” Read at Ars Technica ↗ WiredLC “an attacker needs to guess specific addresses within the target system” Read at Wired ↗ 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. Ars TechnicaLC “this vulnerability can be fixed with a basic code fix, which will require deploying a BIOS/UEFI update” Read at Ars Technica ↗ 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. Ars TechnicaLC “CVE-2026-97631 doesn’t affect home and small office users, or any other users who boot their devices solely from disk drives.” Read at Ars Technica ↗ WiredLC “use the PXE functionality (which is turned on by default)” Read at Wired ↗
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. Ars TechnicaLC “Intel does not include the affected EDK2 functionality in its reference code, though it may be integrated by an OEM board vendor or system manufacturer” Read at Ars Technica ↗ WiredLC “CVE-2026-97631 is not directly applicable to Arm’s product portfolio.” Read at Wired ↗ 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. WiredLC “PixieFail was a vulnerability similar to CVE-2026-97631. It, too, was the result of faulty PXE boot flaws in EDK2.” Read at Wired ↗
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.
What every side reports
- The flaw is CVE-2026-97631, rated 9.5 out of 10, in the PXE Base Code driver of TianoCore EDK II.
- It was found by Alex Matrosov of Anthropic and Dan Holmes of Google, and details became public before the planned January coordinated disclosure.
- Exploitation requires local network access during PXE boot, and home and small-office users are not affected.
- Intel and Arm say their products are not directly affected, though the articles note their code draws on EDK2.
EDK2 other
The EDK2 project (TianoCore) published a public advisory describing the flaw as an incorrect bounds check in the IPv4 and IPv6 ICMP error handlers of the PXE Base Code driver.
“The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers” — Ars Technica
Left2 articles
-
Code-execution flaw in UEFI firmware threatens most servers on planet Earth
Alarmist Opens on the world's servers being threatened by yet another botched vulnerability, then qualifies the risk with exploitation limits.

-
WiredLC ·
Most Servers on the Planet Are Vulnerable to This Firmware Code-Execution Flaw
Alarmist Republishes Goodin's Ars report with a similar headline on most servers being vulnerable, and adds section headings stressing the leak and a lasting bug.

Centre0 articles
No coverage yet.
Right0 articles
No coverage yet.
- 27 Oct 20:25 First Ars TechnicaLC Code-execution flaw in UEFI firmware threatens most servers on planet Earth
- 28 Oct 20:30 +24h 4m WiredLC Most Servers on the Planet Are Vulnerable to This Firmware Code-Execution Flaw
Times are when each article was published, or when we first saw it if the outlet gave no time.
Ask about this story
Loading…