Defenders and data center operators across the globe face a burdensome response to a critical code-execution vulnerability residing in boot-time firmware used by most of the world's server vendors. Tracked as CVE-2026-97631 and carrying a severity rating of 9.5 out of 10, the flaw affects the TianoCore EDK II open-source codebase, which is utilized by hardware makers and cloud providers to construct UEFI firmware for the boot-up sequence. The vulnerability was originally discovered by Alex Matrosov of Anthropic and Dan Holmes of Google, who arranged for a coordinated disclosure scheduled for January. However, plans changed after hardware maker AMI published a pull request detailing the vulnerability and a code fix last month. Once the post drew the attention of the discovering parties, TianoCore Project members published a public advisory, leaving organizations scrambling to assess their exposure. ## Understanding the 16-Year-Old Buffer Overflow CVE-2026-97631 is a memory-corruption flaw dating back 16 years, residing in the PXE-Base Code driver (`NetworkPkg/UefiPxeBcDxe`). This driver permits servers, storage equipment, and other devices to boot utilizing code downloaded from a local network during the pre-execution environment boot phase. During network boots, the driver maintains an open receive request for ICMP error messages, copying each incoming message into a fixed 504-byte field known as `Mode.IcmpError` within its private context structure. The core issue stems from incorrect bounds handling in both the IPv4 and IPv6 handlers (`PxeBcIcmpErrorDpcHandle` and `PxeBcIcmp6ErrorDpcHandle`): * For messages exceeding 504 bytes, the driver continues copying bytes into the field. * It advances the destination pointer by the cumulative length rather than the per-fragment length. * Nothing earlier on the receive path restricts the incoming message length, allowing oversized data to overwrite adjacent memory. This enables malicious insiders or hackers with low-level local network access to send an oversized error message that corrupts the UEFI module running on the CPU at the most privileged execution level (ring 0). ## Impact on the Boot Sequence and Ecosystem Because the exploit executes early in the boot process, it runs before the operating system and firmware can implement defensive measures like Secure Boot or utilize the Trusted Platform Module (TPM). While the initial payloads lack persistence and run only once, they provide a wide opening for attackers to install additional payloads that execute during subsequent early boot sequences. HD Moore, creator of Metasploit and chief research officer at Dragos, noted that the bug allows an attacker to hijack program flow while the boot process still has access to sensitive components like the TPM. This could potentially break disk encryption for adversaries with short-term network access or physical theft scenarios. However, exploitation is not entirely trivial. Jesse Michael, principal researcher at Eclypsium, explained that attackers must guess specific addresses within the target system. Because those addresses vary based on the model, version, and configuration, exploits must be tuned for each individual target. ## Affected Systems and Mitigation Guidance The vulnerability exclusively impacts organizations operating machines that boot from local networks or Internet-connected resources using EDK2-based firmware with PXE functionality enabled by default. It does not affect home and small office users or devices that boot solely from disk drives. Major hardware and silicon manufacturers have responded with varying assessments: * Intel stated that none of its commercial products currently under security support are known to be affected, adding that it does not include the affected EDK2 functionality in its reference code, though OEM board vendors may integrate it. * Arm stated that the vulnerability is not directly applicable to its product portfolio, though its available firmware borrows heavily from EDK2.