TianoCore says a PXE flaw in EDK II code dating to 2010 can run code before Secure Boot; no stable fix

5,834 days from the first commit to the advisory, and what that does not prove

5,834 days (derived) separate the commit that first put the EDK II network package into the project's git history, on 1 November 2010, from the TianoCore security advisory of 22 October 2026. That is 15 years and 11 months (derived), which headlines have rounded up to 16. The advisory, GHSA-99cj-7hg9-mp4m, says a buffer overflow in the PXE Base Code driver, tracked as CVE-2026-97631, lets an unauthenticated sender corrupt memory while a machine is network booting. In the worst case it lets them run code in the firmware before Secure Boot or measured boot has verified or measured any operating system component.

The date does not establish three things. It dates the oldest copy of the copy loop that the fix replaces. It does not show that the flaw was reachable and exploitable in every release since: the advisory itself lists the affected version as "EDK II master as of 2026-09-14". It does not show that anyone has used the flaw: no source read for this briefing reports exploitation, and the CISA Known Exploited Vulnerabilities catalogue of 27 October 2026 (the latest read) does not list it. And it does not say how many servers are exposed, because no firmware vendor advisory read here names an affected product or a fixed firmware build.

This briefing reads TianoCore's advisory, the CVE record, the pull requests and commits in the public edk2 repository, the NVD record, the Debian, Ubuntu, SUSE and Red Hat pages, Microsoft's Project Mu backports, AMI's advisory index and Quarkslab's 2024 write up of earlier flaws in the same package. All were read between 18:40 and 18:58 UTC on Wednesday 28 October 2026. Security Affairs and a mailing list post were also read and are labelled secondary. Two press articles on the story, from The Hacker News and Ars Technica, were not read for this briefing. The finders are credited in the advisory as working at Anthropic and at Google. Anthropic sells AI models and Google sells cloud and AI products, and both gain when they are seen to find flaws; the advisory does not say how the flaw was found, and the CVE record's discovery field reads UNKNOWN.

This is a different problem from the bootkit covered in the earlier BlackX briefing, which concerns malware that gets around Secure Boot. Here no malware is reported. The question is what a firmware network driver does with a packet it should have rejected, and how long a fleet will take to hear that it is fixed.

Stated and not stated: the record, line by line

The table sets what the TianoCore advisory and the CVE record state against what neither states. "Not stated" means not found in the advisory, the CVE record or the pull requests, read in full. It does not mean the information does not exist.

How the bug works, and why "before Secure Boot" is literal

A network boot has a fixed order, described in Quarkslab's 2024 write up of earlier flaws in the same package. The client gets an address from DHCP, learns of a boot server, downloads a network boot program over TFTP, and that program is, in Quarkslab's words, "downloaded, verified (in the case of Secure Boot), and executed". So the firmware's own IP stack is running and receiving packets for the whole time before any verification of what it downloads begins. Quarkslab adds that network boot is popular in data centres and high performance computing, where one image is pushed to hundreds or thousands of nodes.

The advisory's account of the bug is short. During a network boot the PXE Base Code driver keeps a receive request open for ICMP error messages and copies each one into the 504 byte field Mode.IcmpError. The advisory says the bounds handling is wrong in both handlers: for a message longer than 504 bytes the code still copies bytes into the field, and it advances the destination pointer by the cumulative length instead of the length of each fragment, so an oversized message writes attacker controlled bytes past the field. It also says nothing earlier on the receive path restricts the message length.

Zoom

Read plainly, this is the friendly name problem in its purest form. "Secure Boot" sounds like a gate in front of everything that runs at start up. It is a check on the images the firmware is asked to load. A flaw in the firmware's own network driver is not an image anyone asked it to verify, so the check never comes into play (inference from the advisory's wording, not a statement in it). The advisory's phrase "before Secure Boot or measured boot has verified or measured any OS component" also bears on the TPM: a log that records only operating system components would not show what ran before them (inference).

The fix is small and it is public. It zeroes the 504 byte field, limits each fragment copy to the space left, stops once the field is full and moves the destination by each fragment's own length, in both handlers. The figure shows the change, and the full text of the IPv4 hunk is in the Technical details section.

Zoom

Who can send the packet: the sources give different answers

The advisory says the attacker needs only to deliver a unicast ICMP error message to the client's IP "from any network distance". Its CVSS v4 vector says the attack vector is Network, and attack requirements are Present, which the advisory's own glossary describes as prerequisite deployment and execution conditions of the vulnerable system. Red Hat and SUSE, scoring for their own products under CVSS v3.1, chose Adjacent Network and 8.8. A secondary report, from Security Affairs, says the attacker needs some control over the local network and that there is no evidence the flaw gives initial access from outside.

Both framings can be right for different networks. Adjacent fits a dedicated provisioning VLAN where the only reachable senders are on the same segment. "Any network distance" fits a client that accepts an ICMP error from a routed path. Which applies to a given site depends on what its routers and firewalls pass to booting clients, and no source read states that (inference). The practical point: the decision to treat this as a local problem or a routed one is the defender's, and it is made by looking at the boot network, not by reading the score.

Why 16 years: the loop is in the first commit, and the version ranges disagree

The repository shows where the age comes from. The NetworkPkg directory was added to the edk2 repository in commit a3bcde70e6 on 1 November 2010, with the message "Add NetworkPkg (P.UDK2010.UP3.Network.P1)", adding 142 files and 83,988 lines. The file NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c at that commit already holds the running total and the pointer that advances by it, in both the IPv4 and the IPv6 handler. The same lines are in the file at the tags edk2-stable202211 and edk2-stable202608, and not in the file at the fix commit fa789071. The intermediate revisions of the file were not read one by one. The interval from 1 November 2010 to 22 October 2026 is 5,834 days, 15 years and 11 months (derived). Because the git history starts with that import, the code is at least that old; any earlier history is not in the repository.

The advisory and the CVE record do not describe that history. The advisory lists "EDK II master as of 2026-09-14" as affected. The CVE record, assigned by TianoCore, lists the package as affected from version 0 up to edk2-stable202608. Debian's tracker, a third reading, marks its edk2 packages 2022.11, 2025.02 and 2026.08 as vulnerable. The files read agree with Debian and with the CVE record, not with the narrower advisory line. The date in the advisory is probably the date of the code the finders worked from (inference). It should not be read as the date the flaw began.

Zoom

Age is also not a measure of risk. A bug can sit in code for years because nothing was sending the packet that reaches it. What the age does show is that the code is shared: Quarkslab's 2024 list of vendors using this package named Arm, Insyde Software, American Megatrends (AMI), Phoenix Technologies and Microsoft's Project Mu. That list was written for the earlier PixieFail flaws. Whether each of those vendors ships this particular driver, in which firmware, is not stated in any 2026 vendor advisory read.

Fixed in the source is not fixed in your firmware

The word "patched" covers six different states. The advisory says "Not patched currently", while the fix has been in the master branch since 15 October. Both are true: they describe different stages. The table sets the stages against what the record shows. The last stage is the only one that matters to the person running the machine, and it is the one no public source can show.

Two secondary claims need care. Security Affairs reports that the researchers planned to disclose in January, that AMI published a fix last month, and that Intel and Arm say their own products are not directly affected. None of those three was found in a primary source here. AMI's index lists advisories dated 8 September and 13 October 2026 for other CVEs, and none for this one. One fact fits the AMI part without proving it: the first fix commit, and the Project Mu cherry pick of it, carry a signed off line using an AMI mail domain, which suggests an AMI contributor wrote or reviewed the change and does not show an AMI firmware release.

Because a fix was public before the advisory, the window matters. The pull request record shows the first fix opened in the public repository on 28 September 2026, with the CVE id in its title and a description that states the overflow. That is 24 days (derived) before the advisory of 22 October, and the merge to master on 15 October is 7 days (derived) before it. Security Affairs says this revealed details months early. The record read here shows the dates, not whether anyone acted on them. Anyone reading the public repository could see the change, so the safe assumption for a defender is that the flaw was understood outside the finders' circle by early October (inference).

Who found it, and what each party gains

The advisory credits two finders, "for finding this issue and providing the recommended fix": one credited as Anthropic and one as Google. The CVE record repeats the credits as finders. Anthropic sells AI models and Google sells cloud and AI products, and both have a commercial interest in being seen to find security flaws; the advisory and the CVE record do not say whether tools, models or manual work were used, and the record's discovery field reads UNKNOWN. Nothing in the record supports a claim that a model found the bug, and none is made here.

The CVSS score of 9.5 is TianoCore's own, assigned as the CNA for a project made up of developers from software vendors that also use it (Quarkslab's description). Red Hat and SUSE scored 8.8 for their own products; Red Hat's page says its score reflects how the flaw affects its products and can differ from other vendors. A defender should read the lower number as a signal about the attacker's position, not about how much to care.

The friendly name fallacy: Secure Boot, patched and critical

Three labels in this story do the work of a control without being one. "Secure Boot" is a check on loaded images, not on the firmware that loads them. "Patched" is a stage, and the advisory's own "Not patched currently" sits beside a merged fix. "Critical 9.5" is a score for the worst case in the advisory's wording, which needs the target firmware build, while the other effect the advisory lists, a hung boot, is described as deterministic. A team that reads "Secure Boot enabled" in an audit report, "fix merged" in a repository and "critical" in a feed has three comforting or alarming facts and no answer to the question that matters: which of its machines accept this packet while booting.

Technical details

The TianoCore advisory prints no indicators of compromise, no detection rule and no mitigation setting, so this section holds the artifacts it does print: the identifiers, the affected range as the CVE record states it, the vendor scores, the commit hashes and the maintainers' fix. Each block names the source and the date read. Nothing here is a working exploit.

Identifiers and scoring. This is the summary from the TianoCore advisory. A defender uses it to match scanner output, inventory entries and vendor tickets to the right record.

Pre-boot RCE in EDK II PXE driver
GHSA-99cj-7hg9-mp4m
CVE ID: CVE-2026-97631
Published: Oct 22, 2026
Package: NetworkPkg (EDK2)
Affected versions: EDK II master as of 2026-09-14
Patched versions: Not patched currently
Patch: #13302
Severity: Critical, 9.5
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CWE-131 Incorrect Calculation of Buffer Size
CWE-787 Out-of-bounds Write

The CVE record's affected range. This is an excerpt of the CVE record (JSON 5.2), reformatted. It differs from the advisory line above, as the Why 16 years section explains.

{
  "cveId": "CVE-2026-97631",
  "assignerShortName": "TianoCore",
  "dateReserved": "2026-09-24T16:56:45.359Z",
  "datePublished": "2026-10-22T16:32:27.619Z"
}
[
  {
    "vendor": "TianoCore",
    "product": "EDK2",
    "packageName": "NetworkPkg",
    "versions": [
      {
        "status": "affected",
        "version": "0",
        "lessThanOrEqual": "edk2-stable202608",
        "versionType": "custom"
      }
    ],
    "defaultStatus": "unaffected"
  }
]

Distribution and vendor scores. The v3.1 vector is the one Red Hat and SUSE print for their own products.

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   base score 8.8   (Red Hat, SUSE)

Commit hashes and where to look. The Debian tracker and Ubuntu both list these three upstream commits. A firmware team that carries a fork of NetworkPkg checks whether its tree has the fix by looking for these commits or for their cherry picks. Project Mu's backports record the fix commit as the cherry picked source.

14cdbb86a1a4f9bcce0d6cb78b04af58f226cf48  NetworkPkg: Add PXE ICMP fragment-copy tests
560ed9b5b146ed622d7eb7c40254a9099bd65b84  NetworkPkg/UefiPxeBcDxe: Fix ICMP buffer overflow in IPv4/IPv6 handlers (CVE-2026-97631)
fa789071ff0b29f1e568bfe153ef7f3d76bd60e4  NetworkPkg/UefiPxeBcDxe: Clear ICMP error buffer before copying

Project Mu backport trailer (pull requests 1989 and 1990):
(cherry picked from commit 560ed9b5b146ed622d7eb7c40254a9099bd65b84)

The maintainers' fix, IPv4 handler. This is the diff of NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c from pull request 13302, as the GitHub API prints it. Lines starting with a minus are the removed copy loop, and lines starting with a plus are the replacement. The IPv6 handler, PxeBcIcmp6ErrorDpcHandle, has the same change with the names Icmp6Error in place of IcmpError. It is the pattern a firmware engineer greps a fork for.

@@ -252,6 +252,7 @@ PxeBcIcmpErrorDpcHandle (
   UINTN                   Index;
   UINT32                  CopiedLen;
   UINT8                   *IcmpError;
+  UINT32                  FragmentLen;
 
   Private = (PXEBC_PRIVATE_DATA *)Context;
   Mode    = &Private->Mode;
@@ -317,28 +318,20 @@ PxeBcIcmpErrorDpcHandle (
   }
 
   //
-  // Copy the right ICMP error message into mode data.
+  // Copy ICMP error fragments into Mode->IcmpError in order. The maximum
+  // buffer size is sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR); truncate any excess.
   //
-  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;
+  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);
   }
 
 ON_RECYCLE:

Checking a tree, derived. These two commands are this briefing's suggestion for a team that holds its own firmware source, not text from the advisory. The first checks for the upstream fix commit and fails on a tree that cherry picked it, so the second looks for the old pattern and for the zeroing line. Run them only against source you own.

git merge-base --is-ancestor fa789071ff0b29f1e568bfe153ef7f3d76bd60e4 HEAD && echo "upstream fix present"
grep -nE "(Icmp|Icmp6)Error \+= CopiedLen" NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
grep -n "ZeroMem (&Mode->IcmpError" NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c

Not printed anywhere read: network indicators, packet captures, a detection signature, a firmware build list, or a setting that turns the behaviour off. The advisory's impact text is the only guide to what a failure looks like: a boot that hangs on the next ICMP error. A provisioning server that sees clients stall at the PXE stage is the nearest observable (inference).

Ordered checklist for defenders

The exposing question

The fix is public and has been since 15 October, and the advisory says "Not patched currently". Between those two statements sits every server your organisation boots over the network. So which of your machines will accept an ICMP error message while PXE booting, and who has told you in writing which firmware build fixes it?

Key facts