🛒 Arduino, ESP32 & modules
Critical EDK2 UEFI flaw enables PXE-time code execution

Critical EDK2 UEFI flaw enables PXE-time code execution

A 16-year-old buffer overflow in EDK2’s PXE driver lets attackers run code before Secure Boot and TPM, threatening many PXE-booted servers worldwide.

November 3, 20263 min read5 tags

A newly disclosed vulnerability in UEFI firmware used across the server and cloud ecosystem allows code execution before Secure Boot and TPM protections are in place. The bug, CVE-2026-97631, scores 9.5/10 in severity and lives in the open-source TianoCore EDK II (EDK2) codebase.

Where the bug is

The flaw is a buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe), which handles network boot (PXE). During PXE boot, the driver keeps a receive request open for ICMP error messages and copies each message into a fixed 504-byte field, Mode.IcmpError, in its private context.

In both IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle, PxeBcIcmp6ErrorDpcHandle):

  • messages longer than 504 bytes are still copied into the fixed buffer;
  • the destination pointer is advanced by the cumulative length, not per fragment;
  • there is no earlier length restriction on the receive path.

Result: an oversized ICMP error lets an attacker overwrite adjacent data with controlled bytes, corrupting the UEFI module and gaining ring 0 code execution in the firmware environment.

Impact and constraints

The vulnerability affects systems that:

  • use EDK2-based UEFI (including forks like Microsoft’s Project Mu);
  • have PXE network boot enabled (default in many server platforms);
  • boot from a local network or similar infrastructure.

Home and small office systems that boot only from disk are effectively out of scope.

Exploitation requirements:

  • some level of low-level access to the target’s local network (insiders, APT, ransomware groups);
  • knowledge of the target firmware build and addresses – exploits must be tuned per model/version/config;
  • the malicious ICMP error must hit during the PXE boot window.

An attacker can at minimum cause a denial-of-service by hanging the boot. With a tailored exploit, they can plant a counterfeit event that executes arbitrary code before the OS loads and before attestation and Secure Boot checks, potentially undermining disk encryption and remote trust.

Mitigation

Vendors can fix the issue with a straightforward code patch, but it still requires shipping and installing BIOS/UEFI updates across large fleets. No key revocations or Secure Boot database changes are needed, unlike some prior UEFI issues.

Admins should:

  • track and apply firmware updates for all PXE-booted servers;
  • disable PXE where not strictly required;
  • segment PXE networks and filter ICMP where feasible;
  • inventory which platforms rely on EDK2 and PXE.

Given EDK2’s ubiquity and the age of the bug, CVE-2026-97631 is likely to remain a “forever” vulnerability in unsupported and rarely-updated systems.


Source: Gündəm · arstechnica.com