"CVE-2026-97631" — a single identifier for a 16-year-old flaw in EDK II that can let an attacker interfere with or run code on machines while they are booting from the network.
EDK II's PXE code and the 504‑byte overflow
The flaw is a buffer overflow in EDK II's PXE (network-boot) driver. During a PXE boot the firmware listens for ICMP error messages and small status messages from network devices and copies each into a fixed 504‑byte buffer. The size checks in both the IPv4 and IPv6 code are incorrect, so a message longer than 504 bytes can overflow that buffer and overwrite nearby memory with attacker-controlled data.
The ordinary, reliable outcome of that overflow is a crash: the boot hangs and the machine fails to start. A more complex, less reliable outcome is code execution inside the firmware — but only if an attacker builds an exploit tailored to the exact firmware build in use. That code runs before Secure Boot or other boot‑time checks have taken effect; it runs only once but can be used to install code that persists across reboots.
Who and what are affected
The vulnerable code sits in EDK II up to and including edk2-stable202608, the project's most recent stable release dated August 21. EDK II is the reference implementation that vendors use to build UEFI firmware; PXE network boot is turned on by default in EDK II's standard build. The flaw therefore primarily affects servers and data‑center equipment that use PXE — not typical home or office machines that boot from local disks.
The Hacker News traced the faulty copy loop to a commit added in November 2010, making the bug roughly 16 years old in the codebase. How many shipping products include the vulnerable code is unknown.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scramblePatch timeline and release status
A code fix that truncates oversized messages at 504 bytes instead of allowing a spill was merged into EDK II's main development branch on October 15. TianoCore published an advisory on October 22 and rated the flaw 9.5 out of 10. However, no stable release of EDK II includes the fix yet; the advisory still lists the patched version as "Not patched currently." Microsoft’s Project Mu has already pulled the fix into its release branches and cut tagged builds on October 26, but for most operators there is no update to install until firmware makers ship BIOS/UEFI builds built from the fixed source.
Vendor statements and public disclosure
Intel told Ars Technica that none of its “commercial products currently under security support” are known to be affected and that it “does not include the affected EDK2 functionality in its reference code,” though an OEM board vendor or system maker could add it. Arm said the flaw “is not directly applicable to Arm's product portfolio.” AMD, Phoenix Technologies, AMI, Microsoft, and Amazon did not respond to questions before publication, and TianoCore did not respond to Ars Technica’s inquiries, leaving the status of many vendors' products unclear.
Linux distributions also ship the code: Red Hat lists its edk2 package in Red Hat Enterprise Linux 8, 9, and 10 as affected and not yet fixed, and SUSE and Debian mark equivalent packages the same way.
Risk, exploitability, and provenance
The bug can be triggered with a single crafted ICMP or status message sent to the target's address while it is performing a PXE boot; no password or prior access is required. Because the window of opportunity is the short period when a device is network‑booting, Red Hat and SUSE characterize the flaw as exploitable from an adjacent network position rather than from across the open internet.
The vulnerability’s discovery is credited to Alex Matrosov of Anthropic and Dan Holmes‑Mitra of Google; a coordinated disclosure had been planned for January 2027. The schedule was overtaken when a pull request describing the flaw and including the fix was posted publicly on September 28, signed off by an AMI engineer; TianoCore then published its advisory on October 22. With the patch public, Ars Technica warned that skilled actors can study it to learn how the bug is triggered and construct working exploits.
There is no sign the flaw has been used in the wild. It was not in CISA’s Known Exploited Vulnerabilities catalog as of the October 27 update, and no researcher has reported seeing an exploit in operation.
What this means for server operators, Linux distributors, and firmware vendors
- Server operators: If you do not need PXE, disabling network boot reduces exposure. Until firmware updates arrive, watch boot‑time network traffic and logs for anomalous messages during PXE attempts; the advisory lists no other workaround.
- Linux distributors (Red Hat, SUSE, Debian): Your edk2 packages are marked affected and not yet fixed; distribution maintainers must coordinate with downstream firmware builders and platform vendors to get fixed firmware into shipping images and update channels.
- Firmware vendors and OEMs: Although the fix is a straightforward code change, operators cannot install it until vendors ship updated BIOS/UEFI builds. As Eclypsium researcher Jesse Michael told Ars Technica, unlike certificate‑based Secure Boot bypasses this issue “can be fixed with a basic code fix.”
The flaw illuminates a persistent truth in firmware security: code introduced long ago can remain active and widely used, and a single, short window during network boot can be sufficient for a determined actor to halt a server or — if they can tailor an exploit to a particular firmware build — achieve code execution before operating‑system defenses apply. The published fix closes the immediate programming error; the practical question now is how quickly firmware vendors and system builders can convert that source‑level repair into updates their customers can install.
https://thehackernews.com/2026/10/critical-16-year-old-uefi-flaw-can-run.html
