CVE-2026-97631 sits below the controls most security teams monitor. The affected code is the EDK II network stack used during PXE boot. A machine must be network-booting over IPv4 or IPv6, and an attacker must be able to deliver crafted ICMP error messages to it. Under those conditions, the advisory describes memory corruption in the DXE phase that can lead to arbitrary code execution before the operating system loads.
That timing is the main lesson. Endpoint agents, EDR, host firewalls, and operating-system logging are not running yet. Secure Boot may verify the firmware and boot components, but it does not make a running firmware network parser correct. Measured boot may provide evidence about the boot chain, but it does not necessarily prevent an attacker from abusing a vulnerable PXE path during the boot itself.
The advisory rates the issue critical. AMD's bulletin says an unauthenticated attacker who can deliver ICMP error messages can corrupt DXE memory and execute arbitrary code before Secure Boot or measured boot has verified or measured any OS component. EDK II is used in physical firmware and in virtual machine firmware, so the inventory should not stop at laptops.
The network boot path
PXE uses DHCP and TFTP to locate and download boot images. The firmware network stack also processes ICMP responses generated along the route. An attacker on the same network segment, a compromised router, or another system able to inject packets into that path may be in scope. Internet reachability is not required for every deployment, but a poorly segmented provisioning network can be exposed to tenants, guests, contractors, or compromised workloads.
The flaw is not evidence that every device with UEFI is exploitable. The boot mode, network stack configuration, firmware build, and attacker position all matter. The useful operational question is which systems still boot from the network and which networks can deliver ICMP to them during that window.
Inventory firmware and boot policy
Start with the hypervisors. vSphere, KVM, Proxmox, OpenStack, and cloud platforms may ship EDK2-derived firmware images. Record the firmware package version as well as the guest operating system version. A VM template with an old firmware package can keep reproducing the same exposure long after the base image was updated.
Then inventory physical servers and workstations that use PXE or HTTP boot. Check whether network boot is enabled permanently, enabled only for a deployment task, or selected through a one-time boot menu. Servers in a provisioning VLAN deserve special attention because they often sit in a state where network boot remains enabled.
Map the networks that can send DHCP, TFTP, and ICMP to those systems. Guest Wi-Fi, a shared lab VLAN, or a flat management network can break the assumption that provisioning traffic is isolated. Look for both direct paths and paths through a router that permits ICMP errors.
Finally, record the firmware update owner. BIOS and BMC firmware often falls between operating-system patching and hardware support. A server can show a current OS and still run an old firmware image with no recorded change history.
Reduce the window
The most direct control is to apply a fixed EDK2-derived firmware release when the hardware vendor ships one. Track the upstream advisory and the vendor's response because an EDK2 source fix does not automatically update an OEM firmware image. Test the update on the same model and boot configuration used in production.
Where the firmware cannot be updated immediately, reduce network-boot exposure. Disable PXE on systems that do not need it. Turn it off after provisioning or when the deployment task finishes. Isolate provisioning networks from guest, tenant, and general-purpose segments. Restrict which systems can act as DHCP and TFTP servers, and review router ACLs that allow ICMP from untrusted networks into the boot path.
Some administrators may consider filtering fragmented ICMP packets. The AMD bulletin recommends dropping IPv4 ICMP packets with the More Fragments flag or a non-zero fragment offset. That may be a useful containment measure during a PXE window, but it is not a substitute for firmware remediation and it must be tested against the operating network's ICMP requirements.
Verify the fix beyond a version string
After firmware updates, verify the version reported by the hardware management interface and the hypervisor firmware package. Then run a controlled boot test in an isolated lab. Confirm that the expected boot mode works, that secure boot policy remains intact, and that the firmware no longer accepts the malformed ICMP sequence associated with the vulnerability.
Review boot measurements and firmware event logs for unexpected changes. Measured boot can help identify which components were loaded, but teams need to know the expected values before an incident. A clean measurement record is only useful if it is compared with a trusted baseline.
The deeper control is to shorten the period when network boot is possible. A firmware flaw in a rarely used boot path is still dangerous if hundreds of servers sit with PXE enabled for months. Inventory, segmentation, and a one-time boot policy make the attack window smaller even before the next firmware release arrives.