EDK2 UEFI: CVE-2026-97631 flaw in server PXE boot

A critical vulnerability is now public, CVE-2026-97631 (score 9.5 out of 10), in TianoCore EDK II (EDK2), the open source reference code that hardware makers and cloud providers use to build the UEFI firmware that boots servers. The flaw sits in the driver that handles network boot (PXE) and allows code to run before the operating system loads and before Secure Boot verifies any component.

The sources analysed are Ars Technica (republished in full by Wired) and Security Affairs, which quotes the project’s official advisory; for The Hacker News we only have the headline, which confirms the main points.

A disclosure that came early

The flaw was found by researchers at Anthropic and Google, who had agreed on a coordinated disclosure in January. According to Ars Technica, in September AMI published a pull request that described the bug and contained the fix; once the researchers noticed, the TianoCore project released the public advisory. With the patch visible, rebuilding the attack mechanism becomes much easier for skilled attackers, while rolling out firmware updates to millions of machines will take time.

Technical details

The bug is about 16 years old and lives in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe). During network boot the driver keeps a receive request open for ICMP error messages and copies each message into a fixed 504-byte field, Mode.IcmpError. According to the advisory, the bounds handling in the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle) is wrong:

• a message longer than 504 bytes is still copied;
• the destination pointer advances by the cumulative length rather than the per-fragment length;
• nothing earlier on the receive path limits the message length.

The result is a write of attacker-chosen bytes past the field, into the memory of the firmware’s DXE phase. The advisory classifies the issue as Out-of-bounds Write, Classic Buffer Overflow and Incorrect Calculation of Buffer Size, with impact on confidentiality, integrity and availability.

How it is exploited

• The malicious message is a simple unicast to the device’s IP address, sent while PXE boot is in progress, over IPv4 or IPv6, without authentication.
• Invalid data makes the boot hang (DoS).
• Knowing the exact firmware build, the attacker can get their own code executed in the UEFI environment, in ring 0, also bypassing the attestation meant to prove to remote servers that the machine is intact.
• The code is not persistent, but it can be used to install other components that run at every boot.

HD Moore (Dragos), quoted by Ars Technica, notes that at that point the boot process still has access to components such as the TPM: with brief network access, or with a stolen device, an attacker could go as far as breaking disk encryption.

The limits

• Some control over the local network is required: it is a scenario for insiders or attackers already inside, looking to elevate privileges. The sources agree there is no evidence that the flaw works as an initial access vector.
• According to Jesse Michael (Eclypsium), the exploit has to be tuned for each model, version and configuration, because memory addresses change.
• No source reports public exploits or ongoing exploitation.

Relevant MITRE ATT&CK techniques (our mapping) are T1542 Pre-OS Boot (in particular T1542.001, System Firmware) and T1068 Exploitation for Privilege Escalation.

Who is affected

Exposed systems are those with EDK2-based firmware that boot from the network via PXE, a feature that according to Ars Technica is enabled by default. Home and small office devices are not affected, nor is anyone who boots only from disk.

The exact scope is still unclear:

• AMI, Insyde and Phoenix use EDK2 extensively, and Microsoft’s Project Mu also contained the vulnerable component;
• Intel says none of its commercial products still under security support is known to be affected, but a board or system maker may have integrated the feature;
• Arm says the CVE is «not directly applicable» to its products;
• AMD, Phoenix, AMI, Microsoft and Amazon had not answered Ars Technica’s questions at the time of publication.

The sources do not mention virtual machines: many virtualisation platforms use UEFI firmware derived from EDK2, so it is worth asking hypervisor and cloud providers too whether VMs that boot from the network are involved.

Impact for European and Italian companies

PXE boot is common in data centres, automated server provisioning and system image deployment. For NIS2 entities, in particular digital service providers, data centres and cloud providers, the flaw falls under vulnerability management and supply chain security: it calls for a firmware inventory and a formal request to suppliers. In healthcare, where servers and workstations are often prepared over the network, provisioning environments should be checked too. Given how widespread the code is, HD Moore considers it likely that the flaw will live on for a long time in end-of-support systems.

What to do now

1. Take an inventory of the systems that boot from the network and of their firmware (vendor, model, BIOS/UEFI version).
2. Ask server and firmware vendors whether they are affected and when the update will arrive. According to Eclypsium the fix is a regular BIOS/UEFI update: no revocations or Secure Boot key updates (PK, KEK, db, dbx) are needed.
3. Disable PXE boot where it is not needed, at least temporarily, as the sources suggest.
4. Where it is needed, isolate provisioning networks in dedicated segments and limit who can send traffic to machines that are booting (our general advice).
5. Keep TPM and Secure Boot enabled: they remain useful, even though they do not stop this attack.
6. Check network logs for exploitation attempts, for example unusually long or fragmented ICMP error messages towards machines in PXE boot.

How ARXDOME helps

ARX Sentry collects the hardware and system inventory of machines with the agent, a starting point to work out which servers to check with vendors. ARX Watch listens to the network through the probes already installed and also shows devices without an agent, useful so that no machine in provisioning segments is forgotten. Firewall logs collected by ARX Sentry reach the SOC pages, where you can examine the events involving these segments.

Last updated: 28 October 2026