A 9.5-Rated Server Boot Flaw Was Supposed to Stay Secret Until January. AMI Posted the Fix

AMI published a pull request last month describing a memory-corruption vulnerability in TianoCore EDK II and including the code fix, forcing TianoCore Project members to issue a public advisory last week ahead of a coordinated January disclosure planned by Alex Matrosov of Anthropic and Dan Holmes of Google. The bug, tracked as CVE-2026-97631 and rated 9.5 out of 10, is a 16-year-old buffer overflow in the PXE Base Code driver that copies ICMP error messages longer than 504 bytes past a fixed field, letting an attacker write controlled bytes and potentially execute code in ring 0 during network boot before Secure Boot protections start. Ars Technica reported the flaw can be triggered by a simple unicast message sent from any network distance during PXE boot, and that the published diff makes building working exploits "trivial" for advanced hackers while firmware updates must reach millions of devices.

Here is how security disclosure is supposed to work. Someone finds a serious bug. They tell the people who maintain the code, quietly. Everyone agrees on a date. Until that date the maintainers and the downstream vendors write fixes and test them, and nobody says anything in public. On the date everyone publishes together, the patches go out, and the attackers find out about the hole at about the same moment the defenders can start closing it. It’s a bit like a merger announcement: lots of people know, and the whole thing depends on none of them saying so early. Here is how it went this time. Alex Matrosov of Anthropic and Dan Holmes of Google found a memory-corruption bug in TianoCore EDK II, the open-source codebase that hardware makers and cloud providers use to build the UEFI firmware that runs when a machine boots. They planned a coordinated disclosure for January. Then, as Dan Goodin reported at Ars Technica https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ , AMI published a pull request last month that described the vulnerability and included the code fix. When the people who found the bug noticed, TianoCore Project members put out a public advisory https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m last week. The bug is tracked as CVE-2026-97631 and rated 9.5 out of 10. The trouble with a patch is that it tells you exactly where the bug is. A diff that adds a bounds check to a copy loop is a map with an X on it, and Ars says it will be “trivial” for advanced hackers to work out how to trigger the flaw and build working exploits. Meanwhile the defenders have to get firmware updates onto millions of devices sold by thousands of hardware makers and cloud providers, which is slow and fiddly. This came six days after the botched disclosure of the PHP flaws https://rews.cc/a/two-9-2-rated-php-flaws-are-due-for-emergency-patches-0a807d , so it has been a bad month for keeping secrets. 504 bytes The bug itself is old: a 16-year-old buffer overflow in the PXE Base Code driver, the part of the firmware that lets servers, storage gear and other machines boot from code downloaded over a local network. During a network boot the driver listens for ICMP error messages, the network’s way of saying “that didn’t work”, and copies each one into a fixed 504-byte slot. The advisory explains what goes wrong next: The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle : for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length. In plain terms: send an error message that’s too long and the extra bytes get written over whatever sits next to that slot in memory. Ars reports that the message can be a simple unicast sent from any network distance to the target’s IP address, as long as it arrives during the PXE boot. The easy version just hangs the boot. If the attacker knows which firmware build the target runs, the harder version plants a “counterfeit event” that runs the attacker’s code in ring 0, the CPU’s most privileged level, before Secure Boot and the other defenses that build the boot-time chain of trust have started. The payload doesn’t persist; it runs once. But once is enough to install other things that run early in every boot, and exploits can get around the attestation checks that are supposed to prove to remote servers that the hardware is clean. “An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s TPM,” said HD Moore, the creator of Metasploit and chief research officer at Dragos. “This could be used to break disk encryption for cases where an attacker has short-term network access and it would be even easier in a theft scenario .” The caveats They are real. You need some control over a local network, which mostly means insiders or intruders like nation-states and ransomware crews who are already inside and want higher privileges. There’s no evidence yet that the bug gets anyone in the front door. And it isn’t one exploit that works everywhere. “An attacker needs to guess specific addresses within the target system,” Jesse Michael, a principal researcher at Eclypsium, told Ars, so an exploit “needs to be tuned for each target model/version/configuration.” Home and small-office users who boot from disk are unaffected. The exposed machines are ones that boot over a network or conceivably from the internet , run EDK II-based firmware and have PXE switched on, which it is by default. Until they can update, the usual advice is to turn off PXE or confine its traffic to trusted networks https://app.opencve.io/cve/CVE-2026-97631 . Michael also had good news. Unlike BootHole, BlackLotus and Baton Drop, this one needs no key revocations and no update to OS install media, just “a basic code fix” shipped as a BIOS/UEFI update. The bad news is that the BIOS update still has to happen, separately, for each vendor and each model, and plenty of machines will never get one. Moore expects a “forever” bug that lives on in end-of-support systems. The near-universal exposure is a side effect of sharing code. Ars says virtually all the independent BIOS vendors, AMI, Insyde and Phoenix among them, lean heavily on the EDK II reference code, and Microsoft’s hardened Project Mu fork also used the vulnerable component. That’s efficient right up until one bug turns up in the shared code and lands on everyone at once. It has happened in this exact neighbourhood before: in January 2024 Quarkslab disclosed PixieFail https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html , nine bugs in the same EDK II network stack, and CERT/CC’s advisory https://kb.cert.org/vuls/id/132380 listed AMI, Insyde, Phoenix and Project Mu among the affected. Researchers then ran several fuzzing projects over the library looking for more. Apparently none of them caught this one. Quarkslab said it spent about six months working with vendors on a PixieFail patch without leaking anything. That is what the January plan was meant to repeat. It assumed that everyone who knew about the bug would sit on it until January. One of the companies that knew sells firmware fixes, and it published its fix.