The Fix Merged on 15 October. Every Stable EDK II Release Still Carries the Bug.

A severity score of 9.5 and a patched-versions field that reads "Not patched currently" are not supposed to sit on the same advisory. They do on TianoCore's page for CVE-2026-97631, published on 22 October, and both statements are accurate.

The code is fixed. EDK II maintainer Michael Kinney (mdkinney on GitHub) merged pull request #13302 into master on 15 October at 00:09 UTC, and the change is undramatic: corrected bounds handling in both ICMP error handlers, and a ZeroMem on the Mode->IcmpError field before the copy loop in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c. What is not fixed is anything a hardware vendor, a cloud provider or a Linux distribution can pull and build from. The newest stable tag in the repository, edk2-stable202608, was published on 21 August, seven weeks before the fix existed. The CVE record lists every version from 0 through edk2-stable202608 as affected, which is the entire release history of the project.

So the critical firmware vulnerability under most of the world's servers has a public fix, a public exploit path, and no shipping release that contains it. That gap is the story, and it is not really about a buffer overflow.

What the 504 bytes break

During a PXE boot, the PXE Base Code driver keeps a receive request open for ICMP error messages and copies each one into a fixed 504-byte field of its private context structure. The advisory is unusually clear about the defect. The bounds handling is wrong in both handlers, PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle. A message longer than 504 bytes is still copied into the field, and the destination pointer advances by the cumulative length rather than the length of the current fragment. Nothing earlier on the receive path limits the message size.

The delivery requirement is one unicast packet addressed to the client's IP, from any network distance, arriving while the machine is network booting. The exposure window is the duration of that boot.

Two outcomes follow. The deterministic one is memory corruption and a CPU exception inside the DXE core on the next ICMP error, which hangs the boot and denies OS provisioning or recovery. The interesting one needs the attacker to know the target's firmware build. With that, a counterfeit event rides in the same packet and CoreSignalEvent() dispatches attacker-supplied bytes in the DXE phase at ring 0, in the advisory's words, "before Secure Boot or measured boot has verified or measured any OS component."

Ars Technica's Dan Goodin, who reported the flaw on 27 October, describes it as a 16-year-old buffer overflow in code that predates most of the defenses now pointed at it. Payloads delivered this way do not persist, but Ars notes they "can give attackers a wide opening to install other payloads that also run each time early in the boot process."

"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," HD Moore, creator of Metasploit and chief research officer at Dragos, told Ars. "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)."

That TPM sentence is the part to sit with. Disk encryption and remote attestation are both answers to "did this machine start from code we trust," and both are evaluated after the point where this flaw executes. An estate can measure clean and still have been owned before the first measurement was taken. Moore expects it to become a "forever" bug in end-of-support hardware, which is the standard fate of anything that lives in firmware nobody revisits.

The embargo left through a pull request

The disclosure did not fail slowly. It failed in one commit.

Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google found the flaw and had a coordinated disclosure arranged for January, according to Ars. On 28 September, a public pull request appeared on the EDK II repository, #13200, laying out the root cause and carrying a fix. Ars attributes that pull request to AMI, the motherboard and firmware house; the GitHub account behind it is a community login, and the PR itself does not state an employer.

What happened next is legible in the thread. Kinney reviewed it, asked for ICMP unit tests to be added, and pushed a branch with suggested simplifications. No response came. He opened #13302 with his own version, closed #13200 as a duplicate, and merged the replacement on 15 October. The four-commit series carries the bounds correction, the ZeroMem, ICMP fragment-copy tests, and a merge from master. TianoCore published the advisory a week later, on 22 October.

NVD ingested the CVE at 17:17 UTC that day and set it to Deferred at 17:40, twenty-three minutes later. The record has no configurations block, which means no CPE data, which means the asset scanners that match CPE strings against an inventory will not raise this and are not going to. It is not in CISA's KEV catalog. EPSS sits around 0.4%. The CVE record offers no solution and no workaround.

With patch code public and the fix described in a merged PR, building a working exploit is a matter of reading. Ars puts it bluntly: it "will be trivial for advanced hackers."

The pipeline between master and a rack

A merged commit is not a firmware release, and the distance between the two is where this story actually lives.

EDK II cuts stable tags quarterly. edk2-stable202511 landed on 21 November 2025, 202602 on 22 February, 202605 on 22 May, 202608 on 21 August. The next one is due around November, and no fixed tag has been named anywhere, in the advisory or the CVE record. After the tag comes the independent BIOS vendor build for a specific board, then OEM qualification, then a release note, then somebody willing to flash a live fleet. Each step is measured in months. The last step is optional in practice, which is how a 16-year-old buffer overflow is still in production.

Virtual machines do not escape this. The edk2 source package is what distributions build their virtual firmware from, and Debian's tracker currently lists it as vulnerable in bookworm, trixie and forky/sid, with unstable unfixed and bug #1151853 open. Debian's security team marked the trixie entry no-dsa, with the note "Minor issue." Read that next to the 9.5 and you have the shape of the problem: the people who decide whether a patch reaches a package do not agree with the people who scored it.

Three vendors, three severities

The scoring disagreement is not noise. It is three different threat models applied to one bug.

TianoCore, acting as its own CNA, scored it 9.5 on CVSS 4.0 with AV:N, the network vector, and AT:P, attack requirements present. That flag is doing real work. It is the standard's way of saying the attacker needs a condition to hold, in this case a machine mid-PXE-boot, without which the exploit does not land.

Red Hat's analysis scores the same flaw 8.8 on CVSS 3.1 with AV:A, the adjacent-network vector, and flags its own numbers as "preliminary and subject to review" and dependent on how the component reaches its products. Germany's dCERT, in advisory 2026-4043 on 23 October, rated damage HIGH and attack probability MEDIUM-HIGH. Debian called it minor.

AV:N is defensible because ICMP is routable and because network boot is not an accident in a datacenter. It is a scheduled operation that runs in batches: an imaging run across a lab, a cluster reinstall after a board swap, a BMC-triggered reprovision. Each of those is a window, repeated on a calendar, announced by the traffic. AV:A is defensible because in most estates the attacker still has to be on the provisioning segment when the window opens. Both are honest. What follows from the split is less comfortable: the number that determines whether your vendor ships a BIOS update is not the CNA's number, and it is not yours either.

Intel says no, Arm says not applicable, five others said nothing

Scope is the other half of the argument, and the public record on it is thin in a way that should worry anybody with a purchase order open.

Ars reports that virtually all UEFI suppliers use EDK2 extensively, naming AMI, Insyde and Phoenix, and that Microsoft's hardened fork, Project Mu, used the code containing the vulnerable component.

Intel said none of its "commercial products currently under security support" are known to be affected, adding that "Intel does not include the affected EDK2 functionality in its reference code, though it may be integrated by an OEM board vendor or system manufacturer." Arm said the CVE "is not directly applicable to Arm's product portfolio." Both statements are narrower than they will be read. Intel's reference code is public and references EDK2, and TianoCore has described each Intel-supplied UEFI development kit as "a fully validated implementation... for a specific revision of the EDK II source."

AMD, Phoenix Technologies, AMI, Microsoft and Amazon did not answer Ars's questions. Neither did representatives of the TianoCore project.

The fair reading is not that those companies are hiding something. It is that nobody has finished the work of mapping a reference codebase onto a product catalogue, and the honest answer to "are we affected" is currently "we are still counting." There is a real steelman here too. Platforms that never enable the PXE driver, machines that boot only from disk, and networks where the provisioning segment is properly isolated may carry no practical exposure even with the vulnerable code compiled in. There is no evidence of exploitation, and no known path by which this flaw gets an attacker their first foothold. It is a privilege-escalation and persistence tool for somebody who already has a position.

That is a reason to size the risk, not to skip it. The bug sits below every control an organization normally uses to answer the trust question, and the fix sits above every release they can normally deploy.

What a buyer can actually ask

Here is the sentence I would put in a procurement document this week: which BIOS or BMC release carries the NetworkPkg ICMP fix from PR #13302, and on what date will it be available for this specific model?

Not "are you patched." That question gets a yes from a support queue that has not checked. The pull request number will mean nothing to a first-line agent either, so quote the CVE, ask for a firmware release identifier and a date, and write the answer into the contract rather than the meeting notes. Then go find out how many distinct firmware builds are actually running across the estate, because a fleet inventory organized by model number will not tell you and a scanner matching CPEs cannot.

The uncomfortable pattern this month is that the layer below the operating system is where visibility goes to die. PHP2Shell had a patch, a CVE and active scanning within days. This one has a critical score, a public fix, and a patched-versions field that tells the truth: nothing you can install has it yet. The organizations that come out of that gap cleanly will be the ones who knew which firmware they were running before the advisory published, and who had a contractual reason for a vendor to answer the question.

That is a purchasing problem before it is a security problem. The difference between a fleet that can be patched and one that cannot is usually decided at the point of selection, years before anyone writes a CVE. If you are specifying hardware now, or inheriting a fleet you did not choose, and you need the firmware lifecycle mapped against your support and sourcing commitments, let's talk.