A buffer overflow in the ICMP error handler of TianoCore EDK2's PXE boot driver has been sitting undetected for sixteen years. CVE-2026-97631, rated 9.5 out of 10, allows an attacker with local network access to execute arbitrary code at ring 0 — the CPU's most privileged level — before Secure Boot, TPM attestation, or any operating system defense loads. The vulnerability affects virtually every server vendor that uses EDK2-derived UEFI firmware, which is to say virtually every server vendor. The mechanism is almost embarrassingly simple. When a machine performs a PXE network boot, the base code driver opens a listener for ICMP error messages and copies each into a fixed 504-byte buffer. The copy loop has no bounds enforcement. An oversized ICMP message writes attacker-controlled bytes past the buffer boundary, corrupting adjacent memory. Because the driver advances the destination pointer by cumulative rather than per-fragment length, the corruption is predictable and exploitable. A unicast packet from any network distance, sent during the boot sequence, is sufficient. The disclosure was a mess. Alex Matrosov of Anthropic and Dan Holmes of Google discovered the flaw and arranged coordinated disclosure for January. AMI preempted them by publishing a pull request last month that detailed the vulnerability and included the fix. Once the discovering parties noticed, TianoCore published an advisory last week. The patch code is now public, making exploit development straightforward for any advanced attacker. This mirrors the botched PHP disclosure six days earlier — a pattern that should alarm the security community. Exploitation carries real caveats. The attacker needs some control over the local network, limiting the threat to insiders, nation-states, or ransomware operators who have already breached a perimeter. The exploit must be tuned per target model, version, and configuration because memory addresses vary. Home users and machines that boot only from disk are unaffected. But for data centers and cloud providers running thousands of PXE-booting servers, the attack surface is enormous. HD Moore notes the flaw could break disk encryption via TPM compromise — devastating in theft or short-term physical access scenarios. The patching logistics are brutal. UEFI firmware updates must flow from the EDK2 codebase through IBVs like AMI, Insyde, and Phoenix, then through OEMs, then to end users. Unlike a Secure Boot bypass, this fix doesn't require revocation lists or key management — just a BIOS update. But deploying BIOS updates across millions of servers in thousands of organizations is neither fast nor cheap. Moore calls it a "forever bug" that will persist in end-of-life systems indefinitely. Intel and Arm both distanced themselves from the vulnerability, claiming their commercial products aren't directly affected — while their reference code and development kits rely heavily on EDK2. AMD, Phoenix, AMI, Microsoft, and Amazon did not respond. The gap between vendor disclaimers and actual EDK2 dependency is the real story: organizations cannot rely on vendor statements and must audit their own firmware stacks. This is the latest in a parade of UEFI boot-chain vulnerabilities — LogoFail, PixieFail, PKFail, BootHole, BlackLotus — each exploiting the same structural reality: the code that runs before your security stack loads is itself profoundly insecure, and the ecosystem for patching it is glacially slow. Multiple fuzzing campaigns launched after PixieFail failed to catch this 16-year-old bug. The chain of trust is only as strong as its weakest pre-boot link, and that link is rotten.
