Pull to refresh
Logo
What Changed
Following Why Sign Up
UEFI firmware flaw lets network attackers hijack most servers during boot

UEFI firmware flaw lets network attackers hijack most servers during boot

New Capabilities

A 16-year-old buffer overflow in TianoCore EDK II lets network attackers run code before security defenses load, and no stable fix has shipped

October 28th, 2026: No Stable EDK II Release Carries the Fix

Overview

Updated Oct 28

A 16-year-old bug in the firmware that boots most servers lets a network attacker run code before the operating system and Secure Boot load. The flaw sits in TianoCore EDK II, the open-source base behind firmware from AMI, Insyde, Phoenix and Microsoft's Project Mu.

A fix was merged into the main branch on October 15, but no stable EDK II release includes it yet, and the advisory still lists no patched version. Microsoft's Project Mu has tagged builds with the fix, while Red Hat, SUSE and Debian still list their packages as unfixed. Exploitation requires access to the local network during a network boot and per-target tuning, so patching will take time.

Why it matters

Attackers on a local network could hijack servers during network boot, before Secure Boot and disk encryption protect them.

Questions about this story

Free account needed to ask — your question is kept and asked for you right after sign-up. Answers are public.

No questions yet — be the first to ask.

Key Indicators

9.5/10
CVSS severity rating
The buffer overflow in the PXE Base Code driver's ICMP handling is rated 9.5 out of 10.
16 years
Age of the flaw
The vulnerable code has existed in EDK II for 16 years before disclosure.
Most servers
Scale of exposure
Virtually all UEFI suppliers, including AMI, Insyde, and Phoenix, use the vulnerable EDK II codebase.
504 bytes
Unenforced memory copy limit
The driver fails to enforce a 504-byte memory copy limit, allowing oversized ICMP messages to overwrite adjacent data.

Voices

Curated perspectives — historical figures and your fellow readers.

Sign up to generate historical perspectives on this story.

Log in Sign Up

People Involved

AM
Alex Matrosov
Security researcher at Anthropic, co-discoverer of CVE-2026-97631
Co-discoverer of the vulnerability
DH
Dan Holmes
Security researcher at Google, co-discoverer of CVE-2026-97631
Co-discoverer of the vulnerability
 HD Moore
HD Moore
Chief research officer at Dragos, creator of Metasploit
Commented publicly on exploitation scenarios
JM
Jesse Michael
Principal researcher at Eclypsium
Commented on exploitability and patching

Organizations Involved

TianoCore Project
TianoCore Project
Open-source software project
Maintainer of the vulnerable EDK II codebase

Open-source maintainer of EDK II, the UEFI firmware implementation used by most hardware vendors.
AMI (American Megatrends)
AMI (American Megatrends)
Firmware and motherboard vendor
Published the pull request that broke coordinated disclosure

UEFI firmware vendor whose engineer signed off on a pull request detailing CVE-2026-97631 and its fix.
Intel Corporation
Intel Corporation
Semiconductor manufacturer
Says no supported commercial products known to be affected

CPU maker that stated none of its commercial products under security support are known to be affected, though its reference code references EDK2.
Arm Holdings
Arm Holdings
Semiconductor IP company
Says vulnerability not directly applicable to its portfolio

Processor designer that said CVE-2026-97631 is not directly applicable to its product portfolio, despite documented use of EDK2.

Timeline

2010 October 2026

9 events Latest: October 28th, 2026 · 2 weeks ago
Tap a bar to jump to that date

  1. No Stable EDK II Release Carries the Fix

    Latest Status

    As of October 28, the newest stable tag, edk2-stable202608, predates the fix and the advisory still lists no patched version.

  2. Red Hat, SUSE and Debian List Packages as Unfixed

    Status

    Red Hat's edk2 packages for RHEL 8, 9 and 10, along with SUSE and Debian equivalents, are marked affected and not yet fixed.

  3. Ars Technica publishes detailed report on the flaw

    Publication

    Ars Technica describes how the vulnerability works, which vendors are affected, and the challenges of patching.

  4. Project Mu Ships Tagged Builds With Fix

    Patch

    Microsoft's hardened EDK II fork, Project Mu, pulled the fix into its release branches and cut tagged builds.

  5. TianoCore Issues Public Advisory

    Disclosure

    TianoCore published its public advisory on CVE-2026-97631 on October 22, rating it 9.5 out of 10, weeks before the planned January 2027 disclosure.

  6. Fix Merged Into EDK II Main Branch

    Patch

    The fix, which cuts oversized ICMP messages at 504 bytes, was merged into the main development branch. No stable release contained it yet.

  7. Pull Request Reveals Flaw and Fix

    Disclosure

    A pull request signed off by an AMI engineer described the flaw and its fix on September 28, breaking the scheduled January coordinated disclosure.

  8. Researchers Discover CVE-2026-97631

    Discovery

    Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google find the memory-corruption flaw and arrange a coordinated disclosure for January 2027.

  9. Vulnerable ICMP parsing code enters EDK II PXE driver

    Origin

    A buffer overflow in the PXE Base Code driver's ICMP error handling is introduced into the EDK II codebase, about 16 years before disclosure.

Scenarios

1

Working exploits for CVE-2026-97631 appear in the wild

Likely Resolves by Q1 2027

Discussed by: Ars Technica, HD Moore, Jesse Michael

The article states that with publicly available patch code, it will be trivial for advanced hackers to reverse-engineer the flaw and build working exploits. Because the bug runs code before boot-time defenses load, exploitation could be used to break disk encryption or plant persistent payloads. The likeliest trigger is a well-resourced actor with network access targeting specific data centers.

2

Major UEFI vendors ship patched firmware

Likely Resolves by Q2 2027

Discussed by: Jesse Michael (Eclypsium)

Jesse Michael noted this flaw can be fixed with a basic code update, without the key management changes Secure Boot bypasses require. AMI, Insyde, and Phoenix all build from EDK II and can issue patched firmware, but distributing it across thousands of hardware models and getting data centers to deploy it is a multi-year process.

3

New UEFI bootkit exploiting the flaw is documented

Unlikely Resolves by Q2 2028

Discussed by: Security researchers, HD Moore

HD Moore said the bug could let attackers hijack program flow while the boot process still has access to the TPM, enabling attacks on disk encryption. A bootkit built on this flaw would follow the pattern of BlackLotus, which exploited firmware and bootloader weaknesses. No such malware has been reported, and the requirement for network boot and per-target tuning raises the bar.

Historical Context

3 moments from history that rhyme with this story — and how they unfolded.

January 2024

PixieFail (January 2024)

Six vulnerabilities in TianoCore EDK II's network and PXE boot functions were disclosed; the most severe allowed remote code execution during network boot.

Then

Firmware vendors across the ecosystem scrambled to ship patches, and some platforms remained exposed for months.

Now

The disclosure prompted multiple fuzzing projects aimed at surfacing other EDK II flaws, which apparently failed to find this 16-year-old bug.

Why this matters now

The same codebase and the same PXE boot surface that PixieFail exposed produced CVE-2026-97631, showing this class of firmware bug recurs despite scrutiny.

2023

LogoFail (2023)

Rendering bugs in logo images embedded in the UEFI firmware of nearly every hardware maker allowed attackers to subvert the chain of trust and install malicious components before the OS or Secure Boot ran.

Then

Hundreds of PC models were affected, and vendors issued firmware updates over many months.

Now

LogoFail became a landmark demonstration that pre-boot image parsing is a rich attack surface across the UEFI ecosystem.

Why this matters now

Like CVE-2026-97631, LogoFail gave attackers code execution before security defenses load, relying on EDK II's widespread use across hardware vendors.

July 2020

BootHole (July 2020)

A buffer overflow in the GRUB2 bootloader allowed attackers to bypass Secure Boot on most Linux systems and many Windows devices.

Then

The industry pushed coordinated patches across distros and hardware vendors, but the rollout took months and left many systems exposed.

Now

BootHole became a template for the BlackLotus bootkit, which weaponized Secure Boot weaknesses and drove years of revocation updates.

Why this matters now

BootHole shows how a single boot-chain flaw requires ecosystem-wide patching and how such bugs can be turned into persistent bootkits.

Sources

(10)
+4
Ars Technica Slashdot Hacker News Security News The Hacker News oss-security mailing list CMU Software Engineering Institute GitHub Ars Technica The Hacker News