In TianoCore EDK II (EFI Development Kit II), an open reference implementation of UEFI used in most server motherboards, a critical vulnerability (CVE-2026-97631) has been discovered. The vulnerability exists in the PXE driver and can be exploited by sending specially crafted ICMP packets during network booting in IPv4 or IPv6 networks. The attack does not require authentication and allows an attacker to execute their code with UEFI firmware privileges at a stage before control is passed to the operating system, which can be used to bypass the UEFI Secure Boot verification mechanism and substitute malicious components during the boot process.
The problem is caused by a buffer overflow in the ICMP message handler in the UefiPxeBcDxe driver, which is used for PXE booting and accepts ICMP packets during network booting to log network errors. The overflow occurs because incoming error messages are placed into a fixed buffer of 504 bytes without checking the actual size of the received data. If more than 504 bytes are sent in the ICMP packet, the overflowing tail is written beyond the buffer and overlaps with subsequent structures.
An attack can be launched from the global network — it is sufficient to know the victim's IP address and determine the moment of PXE booting. Knowing which firmware is used on Server the victim, the attacker can prepare an exploit taking into account the memory layout of the specific firmware build and exploit the vulnerability to execute code at the DXE (Driver Execution Environment) level, which runs in the zero protection ring.
The EDK II project was opened in 2004 by Intel and is used by all major firmware manufacturers for server systems, data centers, and cloud providers. Among other things, it is utilized in the firmware of AMI, Insyde, and Phoenix. The vulnerabilities are also present in firmware based on Microsoft’s Mu platform, which is a fork of EDK II.
Ein Problem wurde von Vertretern der Unternehmen Anthropic und Google festgestellt und sollte im Januar 2027 koordinativ öffentlich offengelegt werden. Die Informationen mussten jedoch früher veröffentlicht werden, da ein Ingenieur von AMI versehentlich das Embargo verletzte und einen öffentlichen Pull-Request mit einem Fix veröffentlicht hat, aus dem der Kern der Schwachstelle verstanden werden konnte.
Quelle: opennet.ru
