EDK II PXE Driver RCE Before Secure Boot (CVE-2026-97631)

TL;DR

• While a machine PXE-boots over IPv4 or IPv6, an unauthenticated network attacker can send an oversized ICMP error message that corrupts memory in the UEFI boot environment. The corruption executes chosen bytes before the operating system loads. TianoCore published the advisory GHSA-99cj-7hg9-mp4m on October 22, 2026.
• The exposure is any EDK II-based firmware that network-boots, with the PXE listener reachable by the attacker during the boot window. The impact runs before Secure Boot or measured boot has verified or measured any OS component, so those defenses do not apply.
• The TianoCore CVE record rates it Critical, CVSS v4.0 9.5. CISA’s ADP recorded exploitation as none on October 30, 2026, and the CVE is absent from the KEV feed checked on November 1. The cited sources do not provide a public proof of concept; these observations do not rule out undisclosed exploitation.
• The advisory lists no patched release. Isolate PXE and provisioning networks from untrusted traffic, disable network boot where it is not needed, and ask your server vendor whether its firmware includes the fix.

Am I affected?

You are exposed when all of these hold:

• The machine’s firmware includes the vulnerable EDK II PXE Base Code driver or a derivative of it.
• PXE network boot is enabled, and the machine boots or attempts to boot from the network over IPv4 or IPv6.
• An attacker can deliver a unicast ICMP error message to the machine's IP address during that boot window, from any network distance.

Machines that boot solely from a local disk are not exposed. The vulnerability sits in the network-boot path itself.

The Debian packages listed above remain vulnerable; vendor firmware must be checked individually. Identify your firmware, then check whether it network-boots:

# Firmware vendor and version string, to ask the vendor about EDK II content
dmidecode -s bios-vendor
dmidecode -s bios-version

PXE boot is configured in firmware setup, so inventory it per server or via provisioning tooling. Ask the system manufacturer whether the installed firmware includes the vulnerable driver and its fix.

How do I fix it?

The advisory lists no patched version. Until your vendor confirms a fixed firmware image, reduce exposure:

1. Isolate PXE and provisioning VLANs from untrusted networks to restrict delivery of malicious ICMP messages during network boot.
2. Disable PXE and network boot on every machine that does not need it, which removes the vulnerable listener entirely.
3. Ask your server vendor for their firmware plan, and apply the update when it lands. The fix needs a basic code change and a firmware update, with no key revocations or certificate management, per Eclypsium's assessment quoted by Ars Technica.

The limits are plain. Isolation narrows who can reach a booting machine; it does not fix the driver. Disabling network boot removes the exposure only on machines that never need it. Nothing below the network layer stops the overflow itself until a fixed firmware image is running.

What is the root cause?

The PXE driver copies each received ICMP error message into a fixed-size field without a working bound. The loop then walks the destination pointer past that field.

During network boot, the PXE Base Code driver in NetworkPkg/UefiPxeBcDxe keeps a receive request open for ICMP error messages. It copies each message into the fixed EFI_PXE_BASE_CODE_ICMP_ERROR field, Mode.IcmpError, of its mode structure: an 8-byte ICMP header union followed by a 494-byte data array.

The field is defined in MdePkg/Include/Protocol/PxeBaseCode.h:

typedef struct {
  UINT8     Type;
  UINT8     Code;
  UINT16    Checksum;
  union {
    UINT32    reserved;
    UINT32    Mtu;
    UINT32    Pointer;
    struct {
      UINT16    Identifier;
      UINT16    Sequence;
    } Echo;
  } u;
  UINT8    Data[494];
} EFI_PXE_BASE_CODE_ICMP_ERROR;

The copy loop in PxeBcSupport.c handled fragments of the received message, in both the IPv4 and IPv6 handlers, like this before the fix:

  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;
  }

Two defects break the bound. Once the cumulative length exceeds the field, the else branch copies the excess length instead of the remaining capacity. Depending on the fragment layout, that write can exceed the destination field.

The loop also advances IcmpError by CopiedLen, the running total, instead of the current fragment's length, so the write cursor drifts further out of bounds with every fragment. Nothing earlier on the receive path restricts the message length. A single oversized ICMP error message therefore writes attacker-controlled bytes past Mode.IcmpError into the adjacent driver data.

How is it exploited?

The attack is one unicast packet during a boot window, per the advisory:

1. The machine enters a PXE boot over IPv4 or IPv6, and the driver's receive request for ICMP errors goes live.
2. The attacker sends a unicast ICMP error message addressed to the machine's IP address, larger than the IcmpError field and carrying chosen bytes. Any network distance works, as long as the packet reaches the booting client.
3. The receive path hands the message to PxeBcIcmpErrorDpcHandle in IPv4 or PxeBcIcmp6ErrorDpcHandle in IPv6, and the copy loop writes past the field into adjacent memory.
4. The corrupted state produces either a deterministic boot hang or, for an attacker who knows the target firmware build, dispatched attacker-supplied bytes, as described below.

CISA’s ADP recorded exploitation as none on October 30, 2026, and the CVE is absent from the KEV feed checked on November 1. The cited sources do not provide a public proof of concept; these observations do not rule out undisclosed exploitation.

How does the attack flow?

One oversized ICMP error, delivered during a network boot, is enough to corrupt the pre-OS environment.

What can an attacker do?

The advisory describes two outcomes, both unauthenticated and pre-boot:

• A deterministic boot hang. The corruption of the driver's private data produces a CPU exception inside the DXE core on the next ICMP error, so machines fail to boot from the network. That denies OS provisioning and recovery.
• Arbitrary code execution in the boot environment. An attacker who knows the target firmware build can plant a counterfeit event in the same packet and have CoreSignalEvent() dispatch attacker-supplied bytes in the DXE phase. The code runs in ring 0, before any OS security control exists, and before Secure Boot or measured boot has verified or measured any OS component.

The advisory requires delivery of ICMP errors during the PXE boot window; it does not restrict the attacker to the local network. Actual reachability depends on routing, firewalls and the provisioning network’s isolation.

Why does the fix work?

The fix commit 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec rewrites both copy loops with a per-fragment bound. The IPv4 handler now reads:

  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);
  }

Each iteration copies at most the space that remains in the field. It advances the cursor by that same fragment length, and stops once the field is full, so no write can pass the end of Mode.IcmpError.

The IPv6 handler received the identical change, and the merged pull request adds fragment-copy tests for both paths plus a commit that clears the ICMP error buffer before copying. The fix is complete for the ICMP receive path the advisory names.

The fix merged into EDK II master on October 15, 2026. As of November 1, the latest tagged release is still edk2-stable202608, and Debian lists the packages above as unfixed. These sources do not establish the status of every vendor firmware image; obtain confirmation from your vendor.

How do I check if I was compromised?

No indicators of compromise are published in the advisory. Because the vulnerable handler runs before the operating system, OS logs alone cannot rule out exploitation. A failed attempt may leave no useful host record.

The observable signal of the denial-of-service path sits in the provisioning server's logs, not in the booting machine:

# PXE boot requests seen by a dnsmasq or dhcpd provisioning server
grep -h "PXEClient" /var/log/syslog | tail -20

Treat unexplained boot hangs on provisioning networks as a lead, not proof: legitimate network problems cause the same symptom. If your threat model includes a sustained attacker on a provisioning network, rotate the secrets those boot images carry. Verify image integrity out of band after the vendor ships fixed firmware.

Timeline

• 2026-09-24: TianoCore reserves CVE-2026-97631.
• 2026-09-28: AMI opens a public EDK II pull request that names the CVE and includes a fix, breaking the finders' disclosure plan that was scheduled for January, per Ars Technica.
• 2026-10-15: The reworked fix, pull request 13302, merges into the EDK II master branch.
• 2026-10-22: TianoCore publishes advisory GHSA-99cj-7hg9-mp4m and the CVE record.
• 2026-10-27: Ars Technica publishes its analysis of the flaw and the disclosure.
• 2026-10-28: The advisory reaches the oss-security mailing list.
• 2026-10-30: CISA's ADP records no known exploitation.

The embargo broke 24 days before the advisory: AMI's public pull request appeared on September 28 and TianoCore published on October 22.

FAQ

Does this affect machines that boot from their own disk?

No. The flaw lives in the PXE driver’s network-boot path, so a machine that never attempts a PXE boot never opens this receive window. Inventory actual boot behavior and firmware settings instead of assuming network boot is disabled.

Why does Secure Boot not stop this?

The corrupted state and the dispatched bytes run in the DXE phase, before the operating system loads. Secure Boot and measured boot have not verified or measured any OS component at that point. Firmware-level security features that come later in the boot never see the attacker's code.

Is there a firmware update to install yet?

The advisory lists no patched release. The fix merged into EDK II master on October 15, 2026, but the latest upstream tag and the listed Debian packages lack it as of November 1. Ask your vendor whether its firmware includes the fix and apply its update when available.

What does an attacker need to exploit it?

Network reachability to the booting machine, a unicast ICMP error message larger than the field, and knowledge of the target firmware build. Exploitation requires target-specific addresses, so each model, version and configuration needs its own tuning, per Eclypsium.

Is it exploited in the wild?

CISA’s ADP recorded exploitation as none on October 30, 2026, and the CVE is absent from the KEV feed checked on November 1. The cited sources do not provide a public proof of concept; these observations do not rule out undisclosed exploitation.

Why did the disclosure happen now?

The finders, Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google, had scheduled the coordinated disclosure for January. AMI opened a public pull request with the fix and the CVE id on September 28, 2026. Once that came to the finders' attention, TianoCore published the advisory, per Ars Technica.

References

• Advisory GHSA-99cj-7hg9-mp4m, TianoCore, CVSS v4.0 9.5: https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m (published October 22, 2026; checked November 1, 2026)
• CVE-2026-97631 record, TianoCore CNA: https://www.cve.org/CVERecord?id=CVE-2026-97631 (checked November 1, 2026)
• Fix commit 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec in EDK II: https://github.com/tianocore/edk2/commit/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec (checked November 1, 2026)
• Merged fix pull request 13302: https://github.com/tianocore/edk2/pull/13302 (merged October 15, 2026; checked November 1, 2026)
• Embargo-breaking pull request 13200 from AMI: https://github.com/tianocore/edk2/pull/13200 (opened September 28, 2026; checked November 1, 2026)
• Ars Technica analysis of the flaw and disclosure: https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ (published October 27, 2026; checked November 1, 2026)
• oss-security announcement: https://www.openwall.com/lists/oss-security/2026/10/28/4 (published October 28, 2026; checked November 1, 2026)
• Debian tracker for CVE-2026-97631, edk2 packages vulnerable and unfixed: https://security-tracker.debian.org/tracker/CVE-2026-97631 (checked November 1, 2026)
• EFI_PXE_BASE_CODE_ICMP_ERROR definition in MdePkg at the fix commit: https://github.com/tianocore/edk2/blob/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec/MdePkg/Include/Protocol/PxeBaseCode.h (checked November 1, 2026)
• CISA Known Exploited Vulnerabilities catalog, feed checked for CVE-2026-97631: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (checked November 1, 2026)
• EDK II releases: https://github.com/tianocore/edk2/releases