CVE-2026-97631: One ICMP Packet Can Corrupt EDK II Firmware During PXE Boot, and No Fix Has Shipped
Security / news
CVE-2026-97631: One ICMP Packet Can Corrupt EDK II Firmware During PXE Boot, and No Fix Has Shipped
TianoCore rates the 16-year-old overflow 9.5. The fix is merged upstream, no stable EDK II release carries it, and every affected server waits on its firmware vendor.
An unauthenticated attacker who can deliver one ICMP error message to a machine that is booting over the network (PXE, over IPv4 or IPv6) can hang the boot and, against a known firmware build, run code in the DXE phase at ring 0 before Secure Boot checks anything. The flaw is CVE-2026-97631, in the PXE driver of EDK II, the open-source UEFI codebase that AMI, Insyde, Phoenix and Microsoft's Project Mu build firmware from.
The mitigation is to stop network-booting where you can. TianoCore's advisory, published October 22, says "Not patched currently."
What the advisory says about CVE-2026-97631
The TianoCore advisory (GHSA-99cj-7hg9-mp4m) scores it 9.5 under CVSS 4.0, with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The weaknesses listed are CWE-120, CWE-131 and CWE-787.
The PXE Base Code driver (UefiPxeBcDxe) keeps a receive request open for ICMP errors and copies each into a fixed 504-byte field, Mode.IcmpError. The bounds handling is wrong in both the IPv4 and IPv6 handlers, and the destination pointer advances by the cumulative length rather than the per-fragment length. Nothing earlier in the receive path limits message length.
The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google.
Timeline from September 14 to October 28
The score overstates the ease of exploitation. Network distance is rated as network, but an attacker still needs to reach a client that is mid-PXE-boot, and a code-execution exploit has to be built for a specific firmware build. The Hacker News reports the likely result is a crash or a hung boot, and that code which does run does not persist across reboots on its own.
| Date | Event |
|---|---|
| November 2010 | Vulnerable copy loop added |
| August 21, 2026 | edk2-stable202608 tagged |
| September 14, 2026 | EDK II master version the advisory lists as affected |
| September 28, 2026 | Public pull request 13200 names the CVE and carries the fix |
| October 15, 2026 | Fix merged to main in pull request 13302 |
| October 22, 2026 | TianoCore advisory published |
| October 26, 2026 | Project Mu cuts tagged builds with the fix |
The researchers had planned disclosure for January 2027, according to The Next Web. It reports that the pull request from an AMI engineer exposed the flaw early.
Who is affected and who is not
The advisory lists "EDK II master as of 2026-09-14" as affected. The Hacker News says the range runs up to and including edk2-stable202608, so the two sources frame the version range differently. Neither names a patched stable release.
Red Hat lists edk2 in RHEL 8, 9 and 10 as affected and unfixed, and SUSE and Debian mark their packages the same way. Intel says it knows of no supported commercial product that is affected, though an OEM could add the code. Arm says the flaw is not directly applicable to its portfolio. AMD, AMI, Phoenix, Microsoft and Amazon did not answer Ars Technica before publication, according to the Next Web summary of that report.
PXE is enabled by default in EDK II's standard build, per The Hacker News. A server that boots from local disk and never falls back to PXE does not run the vulnerable path. One where PXE precedes the disk, or acts as the fallback, is exposed on every reboot, IT-Connect notes.
What operators can do before firmware updates arrive
The advisory lists no workaround. Operators who do not need PXE can disable it, put the disk first in the boot order, and watch boot-time network traffic. Jesse Michael, a principal researcher at Eclypsium, said the bug "can be fixed with a basic code fix", and The Hacker News reports it does not require revoking keys. NixOS has integrated the patch for OVMF firmware.
No exploitation is reported, and the flaw was absent from CISA's Known Exploited Vulnerabilities catalog as of October 27. For flaws that did ship with fixed versions this month, see our reports on Tailscale's SSH findings, fixed in 1.104.4, and GitLab's CVSS 10 regex flaw. Here, the next milestone is the first firmware vendor bulletin that lists a fixed version.
Sources
More in Security
- 01A Tampered Claude Code Extension Sat in Cursor's Marketplace for 11 Hours and Left an SSH Key BehindVersions 2.1.312 and 2.1.313 carried a 7,386-byte loader that plants an attacker key and a reverse tunnel. Uninstalling the extension does not remove either.
- 02Ivanti Connect Secure Zero-Day Chain Gave Root on a Patched VPN, and the Integrity Checker Misses ItVolexity dates exploitation to October 3, ten days before Ivanti's advisory; the root escalation step has no CVE and no fix in the sources reviewed.
- 03Alpine Logged GitLab CVE-2026-97229 Attacks Nine Days Before CISA Listed ItAlpine's incident report shows the CVSS 10.0 flaw was exploited against its own server on Oct. 20 and 21, and that two GitLab 19.3 builds it ran still carried the bug.
- 04KPMG Could Not Confirm the Deepfake in Capillary's €3 Million FraudCapillary Technologies blamed deepfake cloning in July, but the forensic audit it filed on Oct. 31 calls the loss a payment-diversion scam and says the missing recordings and phone data leave deepfakes unproven.