As reported by SecurityAffairs, a long-overlooked buffer overflow in TianoCore EDK II's PXE Base Code driver has been publicly disclosed as CVE-2026-97631, carrying a CVSS v3 score of 9.5 (Critical). The flaw is notable not for novelty of technique — it is a classic unchecked buffer copy — but for where it sits: in pre-OS firmware that ships in servers from nearly every major vendor.

Security Impact: As reported by SecurityAffairs, a long-overlooked buffer overflow in TianoCore EDK II's PXE Base Code driver has been publicly disclosed as CVE-2026-97631, carrying a CVSS v3 score of 9.5 (Critical).

What Makes This Vulnerability Different

Most high-severity CVEs we triage live in user-space software: web servers, databases, agents. CVE-2026-97631 lives below all of that. The vulnerable driver, NetworkPkg/UefiPxeBcDxe, runs during the DXE phase of UEFI boot — before the OS kernel, before Secure Boot verification completes, before most EDR agents initialize. An attacker who can reach a host with ICMP during its PXE boot window can write attacker-controlled data into a fixed 504-byte field (Mode.IcmpError) without any bounds check, corrupting DXE-phase memory.

The practical implication is severe: security controls that defenders assume are foundational — Secure Boot, measured boot, TPM-based attestation — are themselves running on top of the very component being corrupted. This is the firmware equivalent of being told your burglar alarm was installed by the burglar.

Vulnerability Summary

FieldDetail
CVECVE-2026-97631
CVSS9.5 / Critical
ComponentNetworkPkg/UefiPxeBcDxe (PXE Base Code driver)
Root CauseMissing bounds check on ICMP error copy into Mode.IcmpError (504-byte buffer)
Affected HandlersPxeBcIcmpErrorDpcHandle (IPv4), PxeBcIcmp6ErrorDpcHandle (IPv6)
ImpactArbitrary code execution in DXE phase, pre-OS, pre-Secure Boot
RequirementUnauthenticated local network access; target must be actively PXE-booting
Upstream FixTianoCore EDK II patched; downstream OEM patches required

Who Is Actually Exposed

The threat model matters more than the CVSS here. Exploitation requires three conditions to coincide:

Who Is Actually Exposed
The target must have PXE network boot enabled in firmware settings (many datacenter servers do, for provisioning).
The target must be actively in the PXE boot phase — a narrow window, though repeating on every reboot.
The attacker must be able to deliver ICMP to the target on the local segment — trivial for any compromised host, rogue device, or insider on the same L2 domain.

The populations most at risk are therefore: bare-metal cloud providers offering PXE provisioning, large datacenters that network-boot blade servers, and any environment where PXE remains enabled for convenience after image deployment. Desktops and laptops with PXE disabled in BIOS are not directly exposed.

The 16-year tenure of this bug is a reminder that 'open source = audited' is a myth. EDK II is one of the most security-critical codebases on Earth and has shipped this flaw across millions of devices.

Why Pre-Boot Persistence Matters

Although the article notes the attacker's code does not persist after that boot cycle, defenders should not treat this as a transient impact. A single successful exploitation during a provisioning or maintenance window is enough to:
  • Install a UEFI implant that does persist across reboots and reinstalls.
  • Disable Secure Boot or modify boot variables to load a rootkit.
  • Compromise measured-boot values so TPM attestation reports a clean state the attacker controls.
  • Exfiltrate disk encryption keys held in early TPM interactions.

For cloud providers, this also raises the bar on multi-tenant trust: a malicious customer with L2 access to a PXE-booting host could theoretically compromise the firmware of a machine other tenants later rely on.

Shield53 Recommendations

Immediate Actions

  • Disable PXE boot on all servers that do not require it. Set the boot order to local media only and password-protect the firmware configuration. This is the single most effective mitigation.
  • Inventory PXE-enabled hosts across the estate. Treat any host with network boot active as a critical exposure until patched. Many will surprise you — PXE is often left on after initial deployment.
  • Apply OEM firmware updates as they become available from AMI, Insyde, Phoenix, and your server vendor. Do not assume a single upstream patch from TianoCore covers you — the fix must propagate through each OEM's release pipeline.
  • Isolate PXE traffic on a dedicated, segmented VLAN with strict L2 controls. PXE should never run on a general-purpose production network reachable by unmanaged endpoints.

Detection & Hardening

  • Monitor for ICMP echo/destination-unreachable bursts targeting hosts during boot windows — anomalous ICMP volume is the only network-side signal of attempted exploitation.
  • Enable UEFI Secure Boot and verify it remains enabled post-patch; a firmware compromise can silently disable it.
  • Periodically dump and diff firmware configurations to detect tampering. Tools like chipsec can help establish baseline measurements.
  • For high-assurance environments, consider TPM-based remote attestation to detect deviations from known-good boot state — but recognize that this vulnerability itself can undermine that assurance if not patched first.

The uncomfortable takeaway: firmware supply chains remain the soft underbelly of enterprise security. A single 504-byte buffer, unchecked since 2010, just became one of the highest-impact CVEs of the year. Defenders should treat firmware patching with the same urgency as OS patching — and most do not.