A buffer overflow bug dating back 16 years has been discovered in TianoCore EDK II, the open source codebase that underpins UEFI firmware on most servers and data center hardware. Tracked as CVE-2026-97631 and rated 9.5 out of 10 in severity, the flaw lets an attacker run malicious code before the operating system or Secure Boot protections ever activate.
How the Vulnerability Works
The problem lives in the PXE-Base Code driver, specifically in its handling of ICMP network messages used during network boot (PXE boot). The driver fails to enforce proper memory copy limits when processing a certain type of error message. An attacker who sends a specially crafted ICMP error during the boot sequence can overflow a buffer, overwrite adjacent memory, and seize control at CPU ring 0 - the most privileged execution level on the processor. Because this happens before the operating system loads, standard security tools, antivirus software, and even Secure Boot's integrity checks are not yet running and cannot intervene.
Why Firmware-Level Bugs Are Harder to Contain
EDK II is not a single vendor's product; it is the reference implementation that many hardware makers adapt for their own UEFI firmware. A defect at this layer can ripple across an unusually wide range of servers, workstations, and data center equipment, since so many vendors build on the same foundation. Firmware vulnerabilities are also notoriously persistent: they survive OS reinstalls, disk wipes, and most conventional malware remediation, because the malicious code can execute before any of those defenses load. That makes attestation bypass - tricking a system into reporting a clean, trusted boot state that isn't actually true - one of the more serious theoretical outcomes of this class of bug.
Practical Limits and Mitigation
Exploiting this flaw is not trivial. It requires an attacker to have local network access to a system actively performing a network boot, along with specific tuning to the target environment - it is not a remote, drive-by attack over the open internet. Still, in enterprise settings where PXE boot is used for imaging or provisioning fleets of machines, the exposure window is real.
Security teams are advised to:
- Contact hardware and server vendors for firmware updates addressing CVE-2026-97631
- Disable network boot (PXE) capabilities on systems where it isn't actively required, until patches are deployed
- Audit which systems support network boot and prioritize those in shared or less-trusted network segments
As of now, remediation depends on each hardware vendor shipping its own firmware update derived from the upstream EDK II fix, so patch availability will likely vary by manufacturer and product line.