Your server’s operating system, Secure Boot protections, and TPM attestation all assume they get to run first. A critical memory-corruption flaw in TianoCore EDK II‘s PXE network driver, scored 9.5 under CVSS 4.0, allows an unauthenticated network attacker to execute arbitrary code during network boot, before the OS loads and before Secure Boot or measured boot verifies any OS component.
The scope is still being confirmed vendor by vendor, and not every server is automatically at risk. The systems that are exposed, however, sit at exactly the wrong moment in the boot sequence to defend themselves.
What the Flaw Actually Does
A bounds-checking error in EDK II’s PXE driver lets attacker-controlled data overwrite firmware memory during network boot.
The vulnerable component is NetworkPkg/UefiPxeBcDxe, the PXE Base Code driver in the EDK II network package maintained by TianoCore. The driver copies ICMP error data into a fixed 504-byte field without enforcing the destination boundary correctly.
Its fragment-handling logic advances the destination pointer cumulatively, so attacker-controlled data can overwrite memory beyond that buffer. The attack works while a machine is initiating a PXE boot over IPv4 or IPv6.
A crafted ICMP error message sent to the client’s IP address during that window triggers the out-of-bounds write in the DXE firmware phase, the same phase that initializes hardware and hands control to the boot loader. Code running at that layer operates in the pre-OS firmware environment and has access to sensitive components, including the TPM.
“An unauthenticated network attacker who can deliver ICMP error messages to it can corrupt DXE-phase memory and execute arbitrary code before the operating system loads, before Secure Boot or measured boot has verified or measured any OS component.” TianoCore EDK II security advisory.
Scope, Constraints, and What Vendors Are Saying
Exploitation requires network access during the PXE boot window, and vendor-specific exposure remains unconfirmed across the industry.
Exploitation is not a one-click affair. The attacker needs network reachability to the target during the PXE boot sequence, and reliable code execution may also require knowledge of the specific firmware build and memory layout.
No confirmed in-the-wild exploitation was identified in the cited sources as of the advisory’s publication window between October 22 and October 27, 2026. Exploit-listing claims in other indexes were not independently validated.
Intel stated, according to Ars Technica’s reporting, that its currently supported commercial products are not known to be affected and that its reference code did not include the affected functionality, while acknowledging that an OEM could integrate it independently. Vendor-specific conclusions for AMI, Insyde, Phoenix, Microsoft, AMD, and others remain unconfirmed pending their own advisories.
HD Moore, chief research officer at Dragos, described the practical risk in Ars Technica’s reporting: “An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s TPM.”
What Your Team Should Do Now
Inventory your PXE-dependent systems immediately and contact your firmware vendor before drawing any conclusions about exposure.
Start by identifying every server, appliance, and provisioning system in your environment that uses PXE or network boot. Then determine the firmware vendor, the EDK II revision, and whether NetworkPkg/UefiPxeBcDxe is present in that build.
Contact your system or motherboard manufacturer for a BIOS update or an explicit applicability statement. Where PXE is not operationally required, disable it and restrict network access to provisioning and management segments while you wait for vendor guidance.
Secure Boot and TPM do not prevent this specific pre-boot vulnerability, but keep them enabled. They remain effective against a broad range of other boot-chain threats. Preserve firmware, DHCP, TFTP, and network telemetry for any future incident investigation. To stay safe, review all hardware-layer access points across your environment as part of this remediation effort.
CVE-2026-97631 is a practical illustration of firmware supply-chain risk. When enough products are built from the same reference codebase, a single bounds-checking error can become a remediation project across otherwise unrelated product families simultaneously.
