One oversized error message could be enough to hack a server that boots over the network

One network error message, too long, sent at the wrong moment. It could be enough to run code on a server before its operating system even starts. The vulnerability, tracked as CVE-2026-97631, has been hiding for sixteen years in EDK II, the open-source code from the TianoCore project on which the UEFI firmware (the software that boots the machine) of many manufacturers is built, through vendors such as AMI, Insyde and Phoenix.

TianoCore published its advisory on October 22 and rates the flaw 9.5 out of 10. It was discovered by Alex Matrosov, a researcher at Anthropic, and Dan Holmes-Mitra of Google, according to the advisory. It affects only one specific case, but a common one in data centers: network boot, known as PXE, used to install or redeploy servers in bulk.

What an attacker could do

During a PXE boot, over both IPv4 and IPv6, the firmware's network driver copies the ICMP error messages it receives into a fixed 504-byte memory area. A faulty bounds calculation lets an oversized message overflow it. According to TianoCore's advisory, it is enough to send this message to the machine's address, “from any network distance,” while the boot is in progress.

The certain consequence is a boot failure. The most serious one remains conditional: an attacker who knows the exact firmware version could run their own code before Secure Boot and before any of the system's security tools. HD Moore of Dragos pointed out to Ars Technica, as quoted by Hardware Busters, that the TPM security chip is then accessible, and that bypassing disk encryption is among the realistic uses.

Several specialists urge caution. According to Jesse Michael of Eclypsium, quoted by the same site, exploitation requires guessing memory addresses: the attack must be tailored to each model and each version. The code does not survive a reboot on its own, and no exploitation has been reported.

A patch published too early

Disclosure had been planned for January. According to Ars Technica, quoted by SecurityWeek, AMI's release of a patch forced the timeline. The fix is included in the main EDK II code, but each manufacturer must now rebuild and distribute its firmware. TianoCore's advisory still stated that no fixed version had been released. The good news: unlike older boot vulnerabilities such as BlackLotus, no Secure Boot key revocation is needed.

What to do in the meantime

• If your machines do not boot over the network, disable PXE boot and the UEFI network stack in the firmware settings.
• If you need it, isolate boot traffic on a dedicated network segment.
• Watch the support pages of your server and motherboard vendors for an update that cites CVE-2026-97631, then plan its deployment.

One question remains: how long will manufacturers take to follow? According to Hardware Busters, thousands of manufacturer firmware images must each be rebuilt, validated and then installed.