An EDK II Firmware Flaw Turns Coordinated Disclosure Into a 24-Day Public Pull Request, and No Stable Release Carries the Fix

On October 22 at 14:34 UTC, the TianoCore project published a critical advisory for CVE-2026-97631, a buffer overflow in the PXE network-boot driver of EDK II, the open source UEFI codebase that Ars Technica says suppliers such as AMI, Insyde and Phoenix “use the reference code extensively.” While a machine is PXE-booting, one ICMP error message can write past a fixed buffer in pre-boot memory, before the operating system loads and before Secure Boot or measured boot has verified or measured any OS component. Ars reported it on October 27 under the headline “Code-execution flaw in UEFI firmware affects most servers on planet Earth,” and WIRED republished it as “Most Servers on the Planet Are Vulnerable to This Firmware Code-Execution Flaw.” Both say the discoverers had arranged a coordinated disclosure for January.

I checked that coverage against the project’s own records on the morning of October 29, UTC. A pull request titled with the CVE number and describing the root cause was public on GitHub from September 28, 24 days before the advisory. The fix merged into the main branch on October 15. No stable tag contains it, and the advisory’s own patched_versions field still reads “Not patched currently.” I also read the removed code, ran a small model of its arithmetic, scanned the release tags for it, and compared how Red Hat, SUSE, Ubuntu and Debian rate and track the bug.

The short version:

• The embargo ended in public view, not at the advisory. Pull request #13200 opened on September 28 with the CVE number in its title and a root-cause paragraph in its body. A maintainer was working on it in the open by October 7, a second pull request with tests merged the fix on October 15, and the advisory followed on October 22. The reply in the pull request thread, from the account that published the advisory, says the “embargo was violated due to a mistake.”
• The fix is in the main branch, not in a release. The merge is 429 commits past edk2-stable202608. Microsoft’s Project Mu backported it to 2 of its 8 release branches within hours of the advisory. Debian, Red Hat, SUSE and Ubuntu all still list the bug as open.
• The loop is almost 16 years old, and the advisory’s version range names one snapshot. Both ICMP handlers carried the same arithmetic in the first NetworkPkg commit, on November 1, 2010, and every one of the 35 tags I scanned still has it.
• The one-line description understates the arithmetic. In my model of the removed lines, one message over 1,008 bytes overflows the 504-byte field, and four entries of 100 bytes each (400 bytes in all) write 196 bytes past it. This is arithmetic on offsets, not a test on firmware.
• “Most servers” describes who uses EDK II, not measured exposure. Upstream builds the PXE driver by default, which I checked in the build files, but the vendor questions in the coverage went unanswered and I found no vendor advisory.
• The severity labels split. TianoCore scores it 9.5 (CVSS 4.0, network), Red Hat labels it Critical, SUSE says important, Ubuntu says medium, and Debian’s tracker calls it a “Minor issue” for trixie.

What the advisory says

The advisory (GHSA-99cj-7hg9-mp4m) opens with the claim that matters: “While a machine is PXE-booting over IPv4 or IPv6, an unauthenticated network attacker who can deliver ICMP error messages to it can corrupt DXE-phase memory and execute arbitrary code before the operating system loads, before Secure Boot or measured boot has verified or measured any OS component.” PXE, the Preboot Execution Environment, is how servers fetch a boot program over the network, and DXE is the UEFI phase in which most firmware drivers run.

The defect sits in NetworkPkg/UefiPxeBcDxe. The driver “keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError.” The advisory says the copy loop’s bounds handling is wrong in both the IPv4 and IPv6 handlers, so “an oversized message writes attacker-controlled bytes past the field.” Its impact section limits the exposure: “the exposure window is the duration of the PXE boot,” and the attacker needs only to deliver a unicast ICMP error message addressed to the client’s IP “from any network distance.” The result is either a hang, which the advisory describes as a “denial of OS provisioning / recovery,” or, for an attacker who knows the firmware build, code running in ring 0 in the DXE phase. The finders are credited as Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google), “for finding this issue and providing the recommended fix.”

Three details in the record are easy to miss:

• The version range is one snapshot. The advisory lists the vulnerable range as “EDK II master as of 2026-09-14.” Below I show the same arithmetic in every older tag I scanned.
• The patched-versions field disagrees with the repository. It reads “Not patched currently,” while the pull request the advisory links as the patch merged seven days before the advisory was published. The two statements fit together only if the field means shipped in a release, which is the reading the tag data supports.
• NVD has not analyzed it. The record was published on October 22 at 17:17 UTC with status Deferred, and its only score is TianoCore’s own CVSS 4.0 vector, AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, at 9.5. I recomputed that vector with the cvss library and got 9.5. CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.28) does not list it, and FIRST’s EPSS gave it 0.48 percent on October 28 (percentile 0.415), which for a CVE this new is a placeholder rather than evidence.

The timeline, in UTC

Every row comes from a public record: the pull request pages and their comments, the advisory, NVD, Microsoft’s repository, and the two news reports.

The gaps are the story. The CVE number was in a public title for 24 days and 19 minutes before the advisory, and the merged fix was public for 7 days and 14 hours. The first maintainer activity on the open pull request came about 14 days and 20 hours before the advisory. Ars says the discoverers had planned January, and I could not find that date in any primary record, so I treat it as Ars’s account.

What TianoCore says about it

The project’s reporting page describes a private path: “Discussions, resolution, and patches are completed within GHSA. A date for public disclose is determined, and on that date the issue is made public.” It warns that “Any sharing of unmitigated issues on un-encrypted email or open source prior to embargo expiry may lead to removal from the Infosec group,” and it also says “Priority will be given to reports that include proof-of-concept or exploit code.”

The reply of October 27, posted by the account that published the advisory, is candid. It says GitHub advisories remain “the recommended method for coordinated disclosure,” that “we are currently facing a backlog of reports,” and that “In this particular GHSA example, embargo was violated due to a mistake, resulting in the PR being created in the open. This should be avoided.” The contributor who asked the question had written that “security issues submitted through public PRs, such as this one, appear to receive reviews and fixes much more quickly.” I cannot see the private queue, so I cannot confirm the backlog. What the public list shows is consistent with it: the repository’s published advisories hold 13 real entries since January 2024 (plus a test entry), and none was published between December 9, 2025 and this one, a gap of 317 days.

Whatever the cause, project members reviewed and merged the fix in public over about two weeks while the advisory sat unpublished. Ars covers the leak in two sentences. The records show it lasted 24 days and included the maintainers’ own review and merge, which is a different failure from a leak that someone catches in a day.

PixieFail, for contrast

The last well-known disclosure in this same network stack was PixieFail, coordinated by CERT/CC as VU#132380. The vendor records on that note list 23 vendors, the earliest contact date is August 3, 2023, and the note went public on January 16, 2024, 166 days later. A web search on October 29 turned up no CERT/CC note and no vendor advisory for CVE-2026-97631, so there is no public vendor list to compare against. Last week’s PHP disclosure also leaked early, and I covered how it unfolded in PHP Ships the PHP2Shell Fixes a Day Early After a Leak.

The loop

Almost 16 years in two handlers

Ars calls this “a 16-year-old buffer overflow.” I checked the history through the GitHub API. The first commit that added NetworkPkg, dated November 1, 2010, already holds the same cumulative-length arithmetic in both PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle. That is 15 years, 11 months and 21 days before the advisory, so “16-year-old” is a fair rounding. I matched the pattern in PxeBcSupport.c at 35 tags, from edk2-stable201808 through edk2-stable202608 plus vUDK2017 and vUDK2018, and all 35 have it. Anyone with a shell can spot-check four of the tags and the main branch:

for t in edk2-stable201808 edk2-stable202011 edk2-stable202308 edk2-stable202608 master; do
  printf "%s " "$t"
  curl -s "https://raw.githubusercontent.com/tianocore/edk2/$t/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c" | grep -c "Error += CopiedLen;"
done

edk2-stable201808 2
edk2-stable202011 2
edk2-stable202308 2
edk2-stable202608 2
master 0

Each old tag prints 2, one match for each handler, and the main branch prints 0 because the merged code advances by FragmentLen instead. This check only shows that the copy loop is present. It does not show that a given firmware build includes the driver or lets such a packet reach it.

What the removed lines did

Here is the IPv4 handler’s copy loop as it stood before the fix, from the files changed in #13302:

  CopiedLen = 0;
  IcmpError = (UINT8 *)&Mode->IcmpError;

  for (Index = 0; Index < RxData->FragmentCount; Index++) {
    CopiedLen += RxData->FragmentTable[Index].FragmentLength;
    if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        RxData->FragmentTable[Index].FragmentLength
        );
    } else {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        CopiedLen - sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)
        );
    }

    IcmpError += CopiedLen;
  }

Three things are wrong with it, and the advisory names only some of them. First, the size test compares a running total of fragment lengths with 504, so the test says nothing about where the destination pointer is. Second, the pointer advances by that running total instead of by the length just copied, so from the second entry on, each copy lands further out than the bytes before it. Third, the else branch copies CopiedLen - sizeof (...) bytes, which is the amount by which the message exceeds the field, not the amount that fits. A message that is only a little over 504 bytes copies a few bytes, and a message over 1,008 bytes asks for more than the field can hold. sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR) is 504 because the header’s fields add up to 502 bytes and the 4-byte alignment of the union pads the structure; the script below mirrors the struct with ctypes and prints both numbers.

The merged version clears the buffer, bounds each copy with MIN, and advances by the length actually copied:

  ZeroMem (&Mode->IcmpError, sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR));
  for (Index = 0, IcmpError = (UINT8 *)&Mode->IcmpError, CopiedLen = 0;
       (Index < RxData->FragmentCount) &&
       (CopiedLen < sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR));
       Index++, IcmpError += FragmentLen, CopiedLen += FragmentLen)
  {
    FragmentLen = MIN (
                    RxData->FragmentTable[Index].FragmentLength,
                    (UINT32)(sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR) - CopiedLen)
                    );
    CopyMem (IcmpError, RxData->FragmentTable[Index].FragmentBuffer, FragmentLen);
  }

A model of both loops

I wrote the arithmetic of both loops as a short Python script. It tracks only offsets and lengths, so no memory is written and no packet is built:

# loop_model.py: offsets-only model of the removed and the merged PXE ICMP copy loops (no memory is written)
import ctypes


class Echo(ctypes.Structure):
    _fields_ = [("Identifier", ctypes.c_uint16), ("Sequence", ctypes.c_uint16)]


class U(ctypes.Union):
    _fields_ = [("reserved", ctypes.c_uint32), ("Mtu", ctypes.c_uint32),
                ("Pointer", ctypes.c_uint32), ("Echo", Echo)]


class IcmpError(ctypes.Structure):  # mirrors EFI_PXE_BASE_CODE_ICMP_ERROR in MdePkg PxeBaseCode.h
    _fields_ = [("Type", ctypes.c_uint8), ("Code", ctypes.c_uint8), ("Checksum", ctypes.c_uint16),
                ("u", U), ("Data", ctypes.c_uint8 * 494)]


SIZE = ctypes.sizeof(IcmpError)


def removed_loop(frags):
    copied = dest = 0
    writes = []
    for length in frags:
        copied += length
        n = length if copied <= SIZE else copied - SIZE
        writes.append((dest, n))
        dest += copied  # the removed code advanced by the running total
    return writes


def merged_loop(frags):
    copied = dest = 0
    writes = []
    for length in frags:
        if copied >= SIZE:
            break
        n = min(length, SIZE - copied)
        writes.append((dest, n))
        dest += n
        copied += n
    return writes


def past_end(writes):
    return max([0] + [d + n - SIZE for d, n in writes])


print("sizeof =", SIZE, "| declared fields =", 1 + 1 + 2 + 4 + 494)
print(f"{'fragment table':<22}{'removed loop writes':<44}{'past end':>9}   merged loop writes")
for frags in ([200], [600], [1200], [300, 300], [100, 100, 100, 100], [400, 100, 4], [600, 10]):
    a, b = removed_loop(frags), merged_loop(frags)
    print(f"{str(frags):<22}{', '.join(f'{d}+{n}' for d, n in a):<44}{past_end(a):>9}   "
          f"{', '.join(f'{d}+{n}' for d, n in b)} (past end {past_end(b)})")

Running it on Python 3.13.14 prints:

sizeof = 504 | declared fields = 502
fragment table        removed loop writes                          past end   merged loop writes
[200]                 0+200                                               0   0+200 (past end 0)
[600]                 0+96                                                0   0+504 (past end 0)
[1200]                0+696                                             192   0+504 (past end 0)
[300, 300]            0+300, 300+96                                       0   0+300, 300+204 (past end 0)
[100, 100, 100, 100]  0+100, 100+100, 300+100, 600+100                  196   0+100, 100+100, 200+100, 300+100 (past end 0)
[400, 100, 4]         0+400, 400+100, 900+4                             400   0+400, 400+100, 500+4 (past end 0)
[600, 10]             0+96, 600+106                                     202   0+504 (past end 0)

Read the past end column as bytes written beyond the 504-byte field. Four findings follow from it, all labeled as my reading of the removed code:

• A single entry between 505 and 1,008 bytes copies 504 bytes or fewer and stays inside the field, which is why “longer than 504 bytes” is not by itself the overflow condition. A single entry of 1,200 bytes copies 696 and ends 192 bytes past the field.
• Entry tables overflow without any single entry being large. Four entries of 100 bytes total 400 bytes, below the field size, and the fourth copy starts at offset 600.
• Three entries totaling exactly 504 bytes (400, 100 and 4) put the last copy at offset 900.
• In the last row the removed code asks for 106 bytes from an entry that holds 10, so it also reads past its source.

What the model cannot tell me is how many entries the IP layer can be made to produce for a remote sender, because I did not read that layer or test any firmware. The advisory does not say either. The size of a legitimate ICMP error is a useful comparison: RFC 792 asks for the “Internet Header + 64 bits of Data Datagram,” and RFC 1812 says the message “SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes.” Legitimate error messages therefore sit below the sizes that overflow the field in a single entry.

Who can reach this function

The coverage and the records disagree about position. The advisory says the packet can come “from any network distance.” Ars says “a malicious insider or a hacker who has gained low-level access to a local network can send an error message,” and later that “some level of control over a local network is a prerequisite.” Red Hat and SUSE both score the bug with an adjacent-network vector, CVSS 3.1 AV:A, at 8.8, and TianoCore’s 4.0 vector uses AV:N.

The score difference is smaller than the label difference. With the cvss library, the TianoCore 4.0 vector gives 9.5 with AV:N and 9.0 with AV:A, so it stays Critical either way. The Red Hat and SUSE 3.1 vector gives 9.8 with AV:N and 8.8 with AV:A, which crosses from Critical to High. So the “local network” reading changes the severity band only under CVSS 3.1.

I read the IPv4 handler for what it checks before the copy. It drops the message unless the receive status is an ICMP error, unless the destination is the client’s own address, and unless the ICMP type is one of five error types (destination unreachable, source quench, redirect, time exceeded, parameter problem). It also drops a message whose source is inside the client’s own subnet but is not a valid unicast address there. Nothing in this function ties the message to a request the client sent, and a source outside the subnet is not rejected, which fits the advisory’s wording. Whether routers, firewalls or the IP layer beneath this handler stop such a packet in a real network is something I did not test. Ars quotes Jesse Michael of Eclypsium on the other practical limit: “it needs to be tuned for each target model/version/configuration since the addresses will change based on those.”

Where the fix is

The distribution rows matter beyond bare metal. Debian’s tracker shows that the edk2 source package is where its virtual machine firmware packages (ovmf and qemu-efi-aarch64, among others) come from. Guests that PXE-boot under a distribution’s OVMF could therefore be exposed if that package’s build includes the PXE driver, which upstream’s defaults do (see below). I did not check any distribution’s build flags or boot any image.

Is it “most servers”?

The three headline wordings differ by a verb. The Ars URL says “threatens,” the Ars page title today says “affects,” and WIRED says servers “Are Vulnerable.” The text beneath them is more careful than any of the three. It says the bug “doesn’t affect home and small office users, or any other users who boot their devices solely from disk drives,” that the target firmware must use EDK II’s implementation and the PXE functionality, and that “While it’s possible some platforms are free of EDK2 code, it’s prudent for users of all servers to investigate if CVE-2026-97631 affects them.” It adds that questions sent to AMD, Phoenix Technologies, AMI, Microsoft and Amazon went unanswered when the story ran. So “most” rests on how widely EDK II code is used, not on a count of shipping firmware images that contain this driver.

The one part I could check at the source is the claim that PXE is on by default. In edk2-stable202608, NetworkPkg/NetworkDefines.dsc.inc sets DEFINE NETWORK_PXE_BOOT_ENABLE = TRUE when the flag is not already defined, OvmfPkg/OvmfPkgX64.dsc (line 56) and ArmVirtPkg/ArmVirtQemu.dsc (line 48) set it to TRUE, and NetworkPkg/NetworkComponents.dsc.inc adds UefiPxeBcDxe.inf to the build when it is TRUE. A platform that pulls in NetworkPkg’s components with the defaults gets the vulnerable driver, and the flag, which the file’s own comment describes as enabling or disabling the PXE boot feature, is the switch that leaves it out. What vendors set in their own builds, and which versions they forked from, is exactly what the advisory and the coverage leave unanswered.

What to check this week

This list is my reasoning from the advisory’s own conditions, not vendor guidance, and I have not tested any of it on hardware:

1. Ask for a status. Ask each firmware supplier (server maker, board vendor, hypervisor or distribution) whether UefiPxeBcDxe is in your images, and when a build with the fix ships. I found no published list.
2. Remove the exposure window where you can. The advisory says the window is the duration of the PXE boot. Where network boot is not used, Ars’s advice is to consider “turning off network boot capabilities at least temporarily if possible.” Where it is used, see whether the boot order can try local disks first, so the PXE window opens only when provisioning needs it.
3. Keep provisioning networks small. The attacker needs the client’s address and the right moment, and the handler checks little else. A separate provisioning VLAN narrows who can send to it. A filter at its edge that drops fragmented ICMP error messages, and ones longer than the 576 bytes RFC 1812 describes, follows from the model above, but it is an idea to test with your network team, not something I verified.
4. Watch the open trackers. Debian bug 1151853, Red Hat Bugzilla 2559129 and SUSE Bugzilla 1288045 each track the bug, and Ubuntu still needs triage.
5. If you build EDK II yourself, take the three commits or the current main branch and rebuild. Setting NETWORK_PXE_BOOT_ENABLE=FALSE leaves the driver out, and PXE boot with it.
6. Plan for a firmware update, not a revocation. Ars’s report notes that, unlike Secure Boot bypasses that need revocations, this bug needs only a firmware update. My post on the BlackX bootkit covers why revocations are the harder kind.

What stays open

• Whether a remote sender can make the IP layer hand the handler a multi-entry table, and whether an ICMP error from outside the client’s subnet survives the path to it.
• Which shipping server and board firmware includes UefiPxeBcDxe, at what version, and when each supplier ships a fix.
• Who set the January date, and when the discoverers learned the fix was public.
• Whether anyone used the bug before October 22. No source says so, CISA has not listed it, and a repository named as a proof of concept appeared in the pull request thread on October 29.
• Why the advisory still says “Not patched currently.”

These records will move quickly, so treat every status above as of late morning UTC on October 29. If a stable tag, a vendor bulletin or a KEV entry appears, the table is the part to update.

Related reading

• PHP Ships the PHP2Shell Fixes a Day Early After a Leak, and Attackers Were Probing Before the Patch Landed, the other early-disclosure story of the week.
• A Suspected APT41 Bootkit Beat Secure Boot on Fully Patched Windows, Kaspersky Says, Because the Baton Drop Revocation Is Opt-In, on the revocation problem that this bug avoids.
• Secure Boot’s 2026 Certificate Deadline Is a Firmware Inventory Test, on why firmware inventories decide how fast a fix like this reaches machines.
• A Brotli Flaw Found by OpenAI Codex Security Forced Patches in Node.js, .NET and Python, and Vendors Rate It From Medium to Critical, another bug whose severity label depends on who is rating it.

Sources

• TianoCore, GHSA-99cj-7hg9-mp4m, Pre-boot RCE in EDK II PXE driver (published October 22, 2026), read through the GitHub REST API.
• TianoCore EDK II, pull request #13200, pull request #13302 and its comments and files, and the first NetworkPkg commit.
• TianoCore, Reporting Security Issues, and the tag list.
• TianoCore EDK II build files at edk2-stable202608: NetworkDefines.dsc.inc, NetworkComponents.dsc.inc, OvmfPkgX64.dsc and ArmVirtQemu.dsc, plus PxeBaseCode.h.
• NIST, NVD record for CVE-2026-97631; CISA, Known Exploited Vulnerabilities catalog; FIRST, EPSS data.
• Ars Technica, Code-execution flaw in UEFI firmware affects most servers on planet Earth (October 27), and WIRED’s republished copy (October 28).
• Openwall, oss-security post of October 28.
• Microsoft, Project Mu pull requests #1989 and #1990.
• Distribution trackers: Red Hat, SUSE, Ubuntu, Debian and the Debian edk2 package page.
• CERT/CC, VU#132380, vulnerabilities in EDK2 NetworkPkg IP stack implementation (PixieFail).
• IETF, RFC 792 and RFC 1812.