A critical memory-corruption bug in TianoCore EDK II, the open-source UEFI reference implementation that underpins firmware from most server vendors, lets a remote attacker write out of bounds during network boot. CVE-2026-97631 (GHSA-99cj-7hg9-mp4m) carries a CVSS v4 score of 9.5. The vulnerable code has reportedly been present for about 16 years.

What happened

TianoCore published the advisory on October 22, 2026. The flaw sits in NetworkPkg/UefiPxeBcDxe, the PXE Base Code driver. Two ICMP error handlers, PxeBcIcmpErrorDpcHandle (IPv4) and PxeBcIcmp6ErrorDpcHandle (IPv6), copy incoming ICMP error messages into the fixed 504-byte Mode.IcmpError field of the PXE mode structure.

The copy does not bound the message length. The loop also advances the destination pointer by the cumulative length instead of the per-fragment length, so each additional fragment lands further past the end of the buffer. Nothing earlier on the receive path caps ICMP message size.

The finders are credited as Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google). Press coverage also describes the patch details becoming public before the originally planned disclosure date. We could not confirm the specifics of that account from primary sources.

Technical details

  • Trigger: a unicast ICMP (or ICMPv6) error message larger than 504 bytes, addressed to a client that is in the middle of a PXE boot.
  • Attacker position: the advisory describes the attack as network-reachable at any distance, with no authentication and no user interaction. The practical constraint is timing: the target must be PXE-booting, and the packet must reach it during that window. An attacker on the provisioning VLAN, or one who can spoof traffic toward it, is the realistic threat. Rebooting or re-provisioning a host is the trigger for exposure.
  • Impact: a deterministic crash in the DXE phase, which hangs the boot. For an attacker who knows the exact firmware build, the advisory says controlled corruption could lead to attacker-controlled event dispatch in DXE. That is code execution before Secure Boot policy, the bootloader, the OS, or any EDR is running.
  • Affected versions: the advisory lists “EDK II master as of 2026-09-14”. Downstream vendor firmware images built from older trees may carry the same unbounded copy, so do not read the single listed version as a clean bill of health for older firmware. Check with your OEM.
  • Exploitation: we found no reports of in-the-wild exploitation, and the CVE is not in the CISA KEV catalog as of this writing. Reliable code execution requires per-build knowledge, which raises the bar. A denial-of-service that bricks fleet provisioning is much easier.

Impact

Any server, appliance or cloud bare-metal fleet that network-boots via PXE (IPv4 or IPv6) using EDK II-derived firmware is in scope. That covers bare-metal provisioning systems such as MAAS, Ironic, Foreman and Tinkerbell, as well as diskless and imaging workflows. Firmware-level compromise survives OS reinstalls and sits below host-based detection, so the downside of the code-execution case is a persistent foothold on infrastructure that is often highly privileged.

Status of the fix is unclear. The advisory links PR #13302 and states “Not patched currently”. Other reports claim a fix has been merged into the EDK II master branch. Treat vendor firmware releases as the authoritative source, since EDK II fixes only reach servers through OEM updates.

Mitigation

The advisory lists no workarounds. These steps reduce exposure:

  1. Disable PXE where it isn’t needed. Turn off network boot in BIOS/BMC settings on hosts that boot from local storage or SAN.
  2. Isolate provisioning networks. Put PXE/provisioning on dedicated VLANs. Apply ingress filtering and anti-spoofing so that only the DHCP/TFTP/HTTP boot servers can send traffic to booting clients.
  3. Filter oversized ICMP errors. Where your gear allows it, drop ICMP/ICMPv6 error messages larger than 504 bytes toward provisioning segments. Test this first, since it can interfere with path MTU discovery.
  4. Prefer HTTP(S) boot on controlled segments with tight network access, and check whether your firmware build still exposes the PXE ICMP path.
  5. Track OEM advisories from Dell, HPE, Lenovo, Supermicro and your cloud’s bare-metal vendor. Schedule firmware updates and BMC-driven rollouts as they ship, and keep a rollback plan.
  6. Watch for boot hangs. Unexplained boot failures on PXE-booting hosts, particularly in clusters, may indicate probing or exploitation attempts.

References