A 9.5-Rated Server Firmware Bug Had Its Fix Posted in Public 24 Days Before the Advisory

The fix for CVE-2026-97631 has been public since September 28. The advisory announcing the bug, dated October 22, still lists the patched versions as "Not patched currently." That gap is the story: a fix that exists in a code repository is not a fix that exists on a server.

How the fix got out before the warning

Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google found the flaw, according to the advisory. Ars Technica reports they had arranged a coordinated disclosure for January. Then, on September 28, a pull request numbered 13200 appeared in the tianocore/edk2 repository with the CVE number in its title and a plain-language root cause. Its commit message carries a sign-off from an ami.com address, and Ars identifies AMI, the firmware and motherboard maker, as the party that published it.

That first pull request shows as closed, not merged. I could not tell from the public page why. A second pull request, 13302, with the same title, merged into the master branch on October 15. The advisory followed on October 22, and Ars published on October 27. For 24 days, anyone reading the repository could see exactly which lines were wrong.

Ars argues that makes exploit development straightforward for capable attackers, and also notes that patching UEFI code across millions of deployed devices is slow. That is Ars's assessment. The advisory itself does not say whether anyone has tried.

What the bug does

A server boots from the network. For the duration of that PXE boot, the driver keeps a listener open for ICMP error messages and copies each one into a fixed 504-byte field. The bounds handling is wrong in both the IPv4 and IPv6 handlers, so a longer message writes attacker-controlled bytes past the end of the field.

The advisory says the attacker needs only to send one unicast ICMP error message to the client's IP address "from any network distance" while the machine is PXE booting. The cheap outcome is a hung boot. The expensive one, when the attacker knows the firmware build, is code running at ring 0, before the operating system loads and before Secure Boot or measured boot has checked anything.

HD Moore, creator of Metasploit and now chief research officer at Dragos, told Ars the position matters because the boot process still has access to the TPM at that point. In his reading, that could help break disk encryption, particularly in a theft scenario. Ars adds that Secure Boot and TPM protections do not stop this particular attack.

Why 9.5 overstates the typical risk

Several conditions have to line up. The target must boot from the network, and Ars says the PXE function is on by default in affected firmware. The firmware must be built on EDK II rather than another reference implementation. The attacker needs a foothold on, or a path into, the local network. Home and small office machines that boot only from disk are not exposed.

There is also a tuning cost. Jesse Michael, a principal researcher at the firmware security company Eclypsium, told Ars that an attacker has to guess specific memory addresses, which change by device model, firmware version and configuration. One exploit will not work across a mixed fleet. The advisory's own scoring reflects some of this: it marks attack requirements as "Present."

Michael also pointed to a point in defenders' favor. Unlike BootHole or BlackLotus, this bug can be closed with a basic code fix delivered as a BIOS update, with no key revocations or boot media rebuilds. Neither Ars nor the advisory reports exploitation in the wild.

Who has said what

Intel told Ars that none of its commercial products under security support are known to be affected, adding that it does not include the vulnerable function in its reference code, though an OEM board vendor may. Arm said the CVE "is not directly applicable" to its product portfolio. Ars notes that both companies' published firmware leans heavily on EDK II anyway.

AMD, Phoenix Technologies, AMI, Microsoft and Amazon had not answered Ars's questions when it published. Ars reports that Microsoft's hardened EDK II fork, Project Mu, used the code containing the vulnerable component. TianoCore did not respond either.

The pattern, and what is not known

Ars frames this as the latest in a line of pre-boot flaws: LogoFail, PKFail, BootHole, BlackLotus, and PixieFail, which was also a PXE flaw in EDK II. Moore called this one likely to be a "forever" bug on end-of-support hardware. I did not find a count of how many EDK II network-stack advisories exist, so the pattern claim is Ars's framing, not a measured base rate.

For organizations that boot servers over the network, Ars advises asking the firmware maker for guidance, turning off network boot where possible, and watching logs for exploitation attempts. The date that decides whether this matters is when each vendor ships a BIOS update, and none of the sources reviewed for this story gives one. Until then, the merged fix is a demo.