A vulnerability has been found in the driver that processes ICMP errors received during PXE network boot in TianoCore's UEFI firmware development framework, EDK II. A GitHub security advisory published on October 22, 2026, rates it "Critical" with a CVSS v4 score of 9.5. Under the right conditions, an attacker could execute arbitrary code at the firmware stage, before Secure Boot or measured boot has verified or measured the OS components.
Beyond the flaw itself, what stands out is when the fix became public. Exploitation requires tuning for each hardware model, but the fix appeared in a publicly viewable GitHub pull request (PR) 24 days before the security advisory was published. In other words, anyone could study the fix for clues about the problem before the vulnerability had been formally disclosed. That gap, along with the delay before patched firmware reaches actual devices, is key to assessing the risk.
A flaw that writes past a 504-byte buffer
The vulnerability lies in "UefiPxeBcDxe," the PXE Base Code driver in EDK II's "NetworkPkg." According to the advisory, during network boot the driver keeps a receive request open for ICMP error messages and copies the received data into a fixed-length field in an internal structure, "Mode.IcmpError." That field has 504 bytes allocated.
The problem is that both the IPv4 handler, "PxeBcIcmpErrorDpcHandle," and the IPv6 handler, "PxeBcIcmp6ErrorDpcHandle," fail to properly limit how much data is copied. Messages larger than 504 bytes are still copied, and the destination pointer is advanced by the cumulative length rather than by the length of each data fragment. As a result, when the client receives a long, specially crafted ICMP error message, data is written past the allocated 504-byte area. The advisory also says no mechanism upstream of the receive path limits message length.
This memory corruption can cause two main kinds of harm. One is a CPU exception inside the DXE core when subsequent ICMP errors are processed, which halts the boot process. Even this alone can disrupt network-based OS deployment and system recovery.
The other involves an attacker who knows the target device's firmware configuration and plants a fake event in the packet. Using the memory corruption, the attacker could have "CoreSignalEvent()" process that event and cause attacker-supplied bytes to be executed during the DXE phase. DXE is the stage at which UEFI firmware loads and initializes various drivers, and OS-level security mechanisms are not yet running. The advisory describes the privilege of code execution at this stage as ring 0.
The network conditions required for an attack are relatively simple. If the attacker can send a unicast ICMP error message to the IP address of a client in the middle of a PXE boot, they do not need to be on the same local network, and no authentication is required. However, the flaw can only be attacked while a PXE network boot is in progress. The CVSS v4 vector includes "AV:N/AC:L/PR:N/UI:N," but also "AT:P," which indicates that additional preconditions are needed for the attack to succeed. Those preconditions matter when judging real-world exploitability.
The advisory credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google as the discoverers, and says they also provided a proposed fix. This is not the first time vulnerabilities have been found in EDK II's PXE-related code. In January 2024, Quarkslab disclosed nine vulnerabilities in the PXE (IPv6) stack of the same NetworkPkg as "PixieFail." Affected vendors named at the time included Arm, Insyde, AMI, Phoenix, and Microsoft's Project Mu.
The fix was public 24 days before the formal disclosure
Checking the public record chronologically shows a 24-day gap between the submission of the fix and the publication of the security advisory.
First, the advisory uses the EDK II master branch as of September 14, 2026, as the baseline for affected versions. Fourteen days later, on September 28, PR #13200, containing a commit signed with an AMI email address, was submitted to the public "tianocore/edk2" repository on GitHub.
The PR title explicitly named "CVE-2026-97631" and the affected module, "NetworkPkg/UefiPxeBcDxe." The description identified the root cause as large packets causing data to be written outside an allocated buffer, and set out a fix through added bounds checks and a cap on data length. The change was a single commit with 22 lines added and 30 deleted.
On October 6, the PR's author requested review, and the next day a maintainer asked for a unit test to be added and published a separate branch containing a proposed fix. Then, on October 14, the maintainer closed PR #13200, citing the lack of a response from the author and overlap with PR #13302, which the maintainer had submitted. GitHub shows that PR #13302, with the same title, passed CI and was merged through the merge queue. The formal security advisory was published another eight days later, on October 22.
In short, the fix for CVE-2026-97631 was viewable by anyone through a public PR for 24 days before the formal disclosure. The PR described the fix, of course, not ready-to-use exploit code. Even so, it specifically showed the vulnerable driver, the faulty processing, and how to fix it.
According to Ars Technica, the discoverers had originally been coordinating a joint disclosure for January 2027. In practice, however, the fix itself became public before the security advisory that serves as the common notice. GitHub comments confirm that at least the maintainers and reviewers were looking at the public PR. Whether attackers viewed the PR, or whether the vulnerability has actually been exploited, cannot be confirmed from public information.
More importantly, a fix landing in the upstream repository does not by itself protect users' devices. As of October 28, Debian's security tracker listed the edk2 packages in bookworm, trixie, and forky/sid as "vulnerable," and the fixed-version status for unstable was "unfixed." The same page lists three upstream fix commits, showing that the fix exists but has not yet been reflected in distribution packages.
Updating the firmware on actual PCs and servers requires, in addition to the upstream fix, integration, validation, and distribution by BIOS vendors and device manufacturers. In an October 27 article, Ars Technica reported that it had contacted AMD, Phoenix, AMI, Microsoft, and Amazon but had received no replies as of publication. That is another reason to distinguish between when a fix is completed upstream and when it reaches actual devices.
Note that Debian's tracker classifies this issue in trixie as a "Minor issue" and treats it as "no-dsa," meaning no Debian Security Advisory (DSA) will be issued. The tracker does not state the reason for that decision, so it cannot directly explain the difference from the Critical CVSS v4 rating of 9.5. Still, the severity of a vulnerability itself and its actual impact or response priority in a particular distribution do not necessarily match.
How hard it is to exploit, and what to check before January 2027
To avoid overstating the danger, it is important to note the hurdles that stand between this flaw and arbitrary code execution. The advisory itself says that knowledge of the target firmware build is needed to achieve code execution. Being able to send a crafted packet over the network is not the same as being able to execute arbitrary code.
Jesse Michael, principal researcher at Eclypsium, told Ars Technica that an attacker would have to guess specific memory addresses within the target system. Using the same exploit on different devices would not automatically yield remote code execution; adjustments would be needed for the model, firmware version, and configuration. He also noted that, unlike fixing a Secure Boot bypass, there is no need to revoke certificates, update keys, or update OS or provisioning media; a BIOS/UEFI firmware update is enough.
This observation is reasonable and matters when considering whether attacks could spread widely. An attack that indiscriminately uses the same exploit code against a wide variety of devices and executes arbitrary code on one after another is unlikely to succeed. Even if an attacker has a network path, the need for per-target tuning is a significant constraint.
When the target's model and firmware are known, however, the meaning of that constraint changes. For example, an attacker who has already penetrated a data center and is targeting a specific group of servers could realistically tailor the attack to the environment. The memory addresses needed for tuning are determined by the firmware build and cannot be obtained directly from the published fix diff. Even so, the public PR does reduce the effort needed to find the vulnerable code. The greater concerns here are targeted attacks and devices whose patching is delayed, rather than indiscriminate attacks on large numbers of devices.
In Japan as well, environments that use PXE to deploy operating systems to many servers at once, or to recover over the network after failures, are worth checking. According to Ars Technica, the affected devices are those with EDK II-based firmware that use the vulnerable PXE functionality. Even if PXE is enabled, exposure to this attack path is limited if the device is not actually performing a network boot. Devices that normally boot only from internal storage, such as home or typical office PCs, do not immediately face the same risk. The first step is to check whether the firmware in use is an affected EDK II-derived implementation and whether PXE boot is used.
The key question going forward is how far the delivery of patched firmware progresses by January 2027, the originally planned joint-disclosure date. If major BIOS vendors such as AMI and Insyde ship firmware that incorporates the fix, concern about fixes stalling at the vendor stage will at least ease. Until distribution by device manufacturers and application in the field are complete, however, the remaining risk on users' devices cannot be considered resolved. The status of fixed-firmware shipments and the status of actual deployment should therefore be checked separately.
On the software side, whether the edk2 status in Debian's security tracker changes from "unfixed" to fixed will be one indicator of progress. Meanwhile, if proof-of-concept (PoC) code containing model-specific tuning steps is published, the technical difficulty that has been a barrier to attacks could drop. Whether vendors that had not replied as of October 27, such as AMD and Phoenix, disclose the status of their fixes is also worth watching.
The size of the change in PR #13200, the first one published, was only 22 lines added and 30 deleted. But a small fix is a separate matter from the difficulty of getting patched firmware to every affected device. What matters is not the date the fix was completed but how long it takes to be applied to actual devices. Vendors' shipment status heading into January 2027, and the progress of subsequent updates by device manufacturers, will indicate how long the risk from this vulnerability lingers.