VDe Vector

Critical UEFI flaw threatens servers during network boot

A vulnerability in widely used EDK II code could give attackers access to firmware before the operating system loads.

A critical vulnerability has been found in the open-source UEFI code EDK II, enabling code execution while booting over a network. The flaw mainly affects systems using PXE; the risk appears more limited for ordinary computers that boot exclusively from a local drive.

The vulnerability has been assigned the code CVE-2026-97631. According to the TianoCore project's security advisory, an attacker can send a specially crafted ICMP error message during a PXE network boot. A flaw in the processing of that message can overwrite memory beyond the intended buffer.

In the most serious scenario, this could allow code to be executed in UEFI's DXE phase, before the operating system has loaded. This also happens before Secure Boot checks the software chain. It is unclear whether this also occurs before the checks performed by measured boot. The official security advisory rates the vulnerability as critical and names EDK II versions that were still vulnerable on 14 September 2026.

EDK II is not an end-user programme, but a reference implementation used by manufacturers when building UEFI firmware. Ars Technica writes that AMI, Insyde and Phoenix, among others, make extensive use of the code. This does not mean that all their products are automatically vulnerable: actual exposure depends on the firmware version and on whether PXE functionality is enabled.

The flaw was publicly described by TianoCore on 22 October. The publication followed after details of a fix had become public earlier than planned. Ars Technica reports that researchers Alex Matrosov and Dan Holmes discovered the vulnerability and that disclosure had originally been scheduled for January.

The public security advisory also states that no patched version is yet available. At the same time, the codebase points to a fix added to the main branch in October. That is not the same as a firmware update for a server or motherboard: manufacturers must first integrate, test and distribute the change.

Data-centre administrators and other organisations using network boot should therefore check which firmware and PXE configuration are active and ask suppliers for a specific patch status. Disabling network boot can reduce the risk on systems that do not need the function, but it is not a general solution for all devices. According to the sources consulted, there is no confirmation that the vulnerability has already been actively exploited.

Respond to this article

← Back to the edition