CVE-2026-97631 is a buffer overflow in the network boot code of EDK II, the open source base that much UEFI firmware is built from. TianoCore fixed it on its master branch on 15 October. No stable release carries the fix yet, and the distributions we checked on 28 October list no fixed package.
Who Has a Fix? The Status Table
The table shows what we read on the pages named in it. We last checked them on 28 October 2026. In the Fix column, Unknown means no fix is listed yet or the vendor gave no answer we could read. It never means the product is safe.
- Affected
- Fixed
- Unknown
Read the first column as “is this product exposed” and the second as “is a fix out”. Upstream is the only row with a fix, and it is source code on the master branch, not something you can install. To reach a machine, the fix must be built into each maker’s firmware and shipped as a BIOS or UEFI update.
Red Hat lists edk2 in RHEL 8, 9 and 10 as affected with no erratum, and rates the CVE Critical. Debian’s tracker marks bookworm, trixie and forky as vulnerable and notes trixie as “no-dsa (Minor issue)”. SUSE rates it important, with the state Pending and ovmf packages listed as affected.
Lenovo’s product security index, Insyde’s security pledge page and AMI’s security advisories page showed no advisory for this CVE when we looked. We did not read the Dell, HPE or Supermicro portals, so check yours.
Intel told Ars Technica that none of its commercial products under security support are known to be affected. Intel added that an OEM may integrate the affected EDK2 functionality. Arm said the CVE is “not directly applicable to Arm’s product portfolio”. Those are statements to a journalist, not advisories.
What Does the Bug Do?
During a network boot (PXE, the Preboot Execution Environment), the firmware listens for ICMP error messages. TianoCore’s advisory says the PXE Base Code driver copies each message into a fixed 504-byte field. A longer message is still copied, and the driver moves the destination pointer by the wrong length. The extra bytes land past the end of the field.
The advisory names two outcomes. An oversized message corrupts the driver’s data, and the next ICMP error crashes the firmware and hangs the boot, which stops provisioning and recovery.
An attacker who knows the exact firmware build can go further, according to the advisory. The firmware then runs attacker-supplied bytes in ring 0, before Secure Boot or measured boot has verified or measured any OS component. That makes it a pre-boot remote code execution flaw. Details, timeline and sources are on the CVE-2026-97631 vulnerability page.
Who Is Exposed?
The advisory says the exposure window is the length of a PXE boot, over IPv4 or IPv6. A machine is at risk while it network boots with EDK II based firmware. Ars Technica reports that machines which boot only from local disks are not affected, and that PXE is switched on by default.
Ars names servers and storage equipment as typical network booters. Virtual machines may matter too. Red Hat, Debian and SUSE list their edk2 and ovmf packages as affected, and OVMF is the EDK II based UEFI firmware for virtual machines.
Why Is the Timing Awkward?
The fix code was public before the advisory. A public pull request, #13200, opened on 28 September already carried the CVE id in its title and described the root cause. TianoCore closed it unmerged on 14 October and merged a reworked fix with unit tests, #13302, on 15 October. The advisory followed on 22 October.
Ars Technica reports that the researchers had planned a coordinated disclosure for January. It also writes that public patch code makes it easier for skilled attackers to learn how the bug is triggered. The CISA Known Exploited Vulnerabilities catalog, in its release of 27 October, does not list the flaw.
How Hard Is It to Exploit?
The sources differ on who can send the message. The advisory says “from any network distance”. Ars Technica writes that a malicious insider or an attacker with low-level access to a local network can send it. Both agree the message must arrive while the target is PXE booting.
Jesse Michael of Eclypsium told Ars that an exploit has to be tuned for each target model, version and configuration, because the memory addresses change. A hang is simpler than code execution: the advisory calls the corruption deterministic.
What Should You Do Now?
- Ask your server and firmware vendors whether their firmware is built on EDK II and when the update ships.
- Turn off PXE or the UEFI network stack in firmware setup on machines that never network boot. Ars suggests doing so at least temporarily.
- Keep PXE and provisioning networks apart from other networks. This is our advice, not a vendor workaround.
- During provisioning, watch your logs for unusual ICMP error traffic aimed at hosts that are PXE booting.
- Plan the firmware update. Eclypsium told Ars that it needs no revocations or key updates, unlike the Secure Boot bypasses in the next paragraph.
Our post on the BlackX UEFI bootkit covers a Secure Boot bypass that Kaspersky reports on patched Windows machines. There, a manual revocation step is needed on top of the patch. Our CVE-2024-8105 post covers PKfail, where firmware trust broke in a different way.