← Back to Feed CACHED · 2026-10-27 23:48:25 · CACHE_KEY CVE-2026-97631
CVE-2026-97631 · CWE-120 · Disclosed 2026-10-22

TianoCore EDK2 PXE ICMP error handler pre-boot buffer overflow via oversized packet

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A poisoned ICMP packet during PXE boot is like slipping malware into the delivery room — the server is compromised before its immune system even wakes up

CVE-2026-97631 is a classic buffer overflow in TianoCore EDK2's UefiPxeBcDxe driver — the ICMP error handler in PxeBcSupport.c copies incoming ICMP error payloads without verifying the packet size against the fixed 504-byte receive buffer. An attacker who can inject a crafted oversized ICMP error response on the same L2 segment as a PXE-booting host overwrites adjacent UEFI memory with attacker-controlled data, achieving arbitrary code execution *before* the OS, Secure Boot, or TPM protections engage. Affected versions are all EDK2 releases through edk2-stable202608; the fix landed in PR #13302, merged October 15, 2026, adding boundary checks and ZeroMem() pre-clearing of the ICMP buffer. The vulnerability was discovered by Alex Matrosov (Anthropic) and Dan Holmes (Google), with coordinated disclosure originally planned for January 2027 — blown early when AMI prematurely published a fix PR. Every major UEFI vendor (AMI, Insyde, Phoenix) and OEM (Dell, HPE, Lenovo, Supermicro) ships EDK2-derived firmware; Intel and Arm have both stated their own current products are not *directly* affected, but downstream integrations remain an open question.

The CNA (TianoCore) assigned CVSS 4.0 9.5 Critical and Red Hat scored it 8.8 High (CVSSv3). Both scores reflect the devastating *impact* — pre-OS code execution — but overweight the *reachability*. The CVSS vector marks AV:N (Network), which is technically correct for ICMP, but misleading: exploitation requires L2 adjacency to a host that is actively PXE booting, a window that in production environments lasts seconds to minutes and occurs primarily during provisioning or reimaging cycles. Servers sitting on local disk don't trigger the vulnerable code path at all. Intel and Arm's disclaimers, the absence of any public PoC, and zero observed exploitation in the wild all confirm this is not yet a weaponized threat — but the public fix commit gives attackers a road map. For a 10,000-host fleet, the realistic exposure is the subset of servers on provisioning VLANs during boot events, not the entire estate. HIGH is the right call — not CRITICAL.

"Pre-boot ICMP overflow in EDK2 PXE driver hits servers hard, but only during the narrow network-boot window"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Attain L2 network position on provisioning VLAN

The attacker must be on the same Layer 2 segment as the target host's PXE boot interface. In data centers this is typically the out-of-band provisioning or management VLAN. This could come from a compromised management host, a rogue device on the provisioning network, or ARP/DHCP poisoning from an adjacent compromised server. Cloud providers with shared provisioning networks face analogous risk.
Conditions required:
  • L2 adjacency or ability to inject/spoof ICMP on the target's PXE VLAN
  • Prior compromise of a host on the same segment, or physical/rogue device access
Where this breaks in practice:
  • Enterprise provisioning VLANs are typically isolated and access-controlled
  • Data center switches enforce port security and DHCP snooping
  • Requires an initial foothold — this is a post-initial-access attack
Detection/coverage: DHCP snooping alerts, 802.1X NAC failures, rogue device detection on management VLANs
STEP 02

Wait for or trigger a PXE boot event

The target must be actively PXE booting — requesting a DHCP lease with PXE options and initiating a TFTP transfer. In production, this happens during server provisioning, reimaging, or recovery. The window is typically seconds to a few minutes. An attacker with BMC/IPMI access to the target could force a PXE reboot, widening the window.
Conditions required:
  • Target has PXE boot enabled in UEFI firmware (default on most enterprise servers)
  • Target is actively performing a PXE boot cycle
Where this breaks in practice:
  • Production servers boot from local disk 99%+ of the time
  • PXE boot events are rare outside provisioning windows
  • Timing the attack to the boot window is non-trivial without BMC access
Detection/coverage: DHCP server logs showing PXE boot requests, NetFlow analysis for TFTP traffic patterns
STEP 03

Send crafted oversized ICMP error response

The attacker sends an ICMP Destination Unreachable or similar error message with a payload exceeding 504 bytes to the PXE-booting host. The vulnerable PxeBcSupport.c ICMP handler copies this payload into a fixed-size buffer without length validation, causing a heap-based buffer overflow. Both IPv4 and IPv6 ICMP handlers are affected. No weaponized tooling is publicly available, but the fix diff in PR #13302 provides a clear blueprint for crafting the malicious packet using raw socket libraries like scapy.
Conditions required:
  • Ability to send raw ICMP packets to the target during PXE boot
  • Knowledge of the buffer overflow trigger (publicly available from the fix commit)
Where this breaks in practice:
  • No public PoC or exploit tool exists as of 2026-10-28
  • Crafting a reliable exploit for pre-EFI memory layout requires firmware-specific knowledge
  • ICMP rate limiting on switches could interfere with delivery
Detection/coverage: IDS signatures for oversized ICMP error payloads (>504 bytes), anomalous ICMP traffic on provisioning VLANs
STEP 04

Achieve pre-OS arbitrary code execution

The buffer overflow overwrites adjacent UEFI DXE driver memory with attacker-controlled data, hijacking execution flow. Code runs in the UEFI DXE phase — ring -2, before the OS loader, Secure Boot verification, or TPM measurements. The attacker has full control of the CPU and memory at the highest privilege level. However, the payload is non-persistent by default — it executes once during this boot cycle only.
Conditions required:
  • Successful heap overflow with controlled write primitive
  • Compatible memory layout on the target's specific firmware build
Where this breaks in practice:
  • UEFI memory layouts vary across OEM firmware builds — exploit must be tailored
  • ASLR-equivalent randomization in some modern UEFI implementations complicates reliability
  • Single-shot: no persistence without installing a bootkit or SPI flash write
Detection/coverage: TPM PCR measurement mismatches on subsequent attestation, Secure Boot violation events if attacker modifies boot chain
STEP 05

Chain to persistent pre-boot implant (optional escalation)

From the DXE-phase code execution, the attacker can write to SPI flash to install a persistent UEFI bootkit, modify the OS bootloader, or inject a malicious DXE driver. This step converts the single-shot exploit into a persistent implant surviving OS reinstalls and disk wipes. On a hypervisor host, this means code execution below all guest VMs. On a domain controller, it means compromise of the identity trust root.
Conditions required:
  • SPI flash write protection disabled or bypassable
  • Knowledge of target firmware's SPI layout
  • Sufficient execution time before OS handoff
Where this breaks in practice:
  • Modern platforms with Intel Boot Guard or AMD Platform Secure Boot block SPI flash modifications
  • HP Sure Start, Dell SafeBIOS, and similar OEM protections detect firmware tampering
  • Hardware-rooted attestation (e.g., Project Cerberus) can detect implants
Detection/coverage: Firmware integrity monitoring (CHIPSEC, Binarly FwHunt, eclypsium), SPI flash hash comparison, Intel Boot Guard violation alerts
03 · Compensating Control

1
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Disable PXE boot in UEFI firmware on all production servers not actively being provisioned — The vulnerable code path only triggers during PXE boot. Disabling PXE network boot in UEFI settings eliminates the attack surface entirely for that host. Use BMC/IPMI or OEM management tools (iDRAC, iLO, XCC) to enforce boot-from-disk-only as the default boot order. Under the noisgate mitigation SLA for HIGH, deploy within 30 days across the fleet. Re-enable PXE only during planned provisioning windows.
2
HIGH 7.5→MEDIUM 4.5
SEVERITY REDUCED
Isolate provisioning VLANs with strict ACLs and 802.1X enforcement — If PXE boot must remain enabled, ensure provisioning networks are isolated with L2 segmentation, DHCP snooping, dynamic ARP inspection, and 802.1X port authentication. This prevents an attacker from reaching the provisioning VLAN from compromised production hosts. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
3
HIGH 7.5→HIGH 6.5
Deploy IDS signatures for oversized ICMP error payloads on provisioning segments — Write or deploy IDS/IPS rules that alert on ICMP Destination Unreachable or Time Exceeded messages with payloads exceeding 504 bytes targeting hosts on provisioning VLANs. This provides detection-in-depth while the firmware remains unpatched. Suricata and Snort can match on ICMP payload length. Deploy within 30 days.
4
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Apply edk2 package updates on OVMF/virtual machine firmware — For virtualized environments using OVMF (Open Virtual Machine Firmware) derived from EDK2, update the edk2 package via dnf upgrade edk2 on RHEL/CentOS or equivalent package manager. This patches the guest UEFI firmware. RHSA-2026:18465 covers RHEL 10; watch for RHEL 8/9 advisories. Under the noisgate remediation SLA for HIGH, complete within 180 days.
5
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Apply OEM firmware updates when available — Monitor Dell (DSA), HPE (SPP), Lenovo (XCC), and Supermicro firmware release channels for BIOS updates incorporating the EDK2 fix. No OEM patches have been confirmed as of 2026-10-28. Firmware updates require maintenance windows and often physical or BMC access. Under the noisgate remediation SLA for HIGH, complete within 180 days. Prioritize hypervisor hosts and domain controllers.
What doesn't work
  • Secure Boot — the exploit fires during the DXE phase *before* Secure Boot verification of the OS bootloader. Secure Boot does not protect the PXE driver itself.
  • OS-level EDR/AV — the vulnerability is pre-OS. No endpoint agent is loaded when the exploit executes. EDR cannot detect or prevent firmware-level code execution.
  • Blocking all ICMP at the network edge — the attack occurs on internal provisioning VLANs, not from the internet. Blocking ICMP on perimeter firewalls has zero effect. Blocking ICMP on provisioning VLANs entirely would break PXE/TFTP error handling.
  • TPM attestation alone — TPM measures boot components *after* the DXE phase. The exploit runs during DXE, meaning the measurement chain is already compromised. Attestation might detect a *persistent* implant on subsequent boots, but cannot prevent the initial exploitation.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity detected as of 2026-10-28. The vulnerability was disclosed prematurely when AMI published a fix PR before the coordinated January 2027 disclosure date.
Proof-of-Concept AvailabilityNo public PoC. No repositories found on GitHub named after CVE-2026-97631. Not indexed on pocindex.io. The merged fix in PR #13302 details the exact buffer copy flaw and provides a reverse-engineering blueprint, lowering the bar for skilled researchers.
EPSS Score0.00432 (0.43%) — bottom quartile. FIRST's model rates exploitation probability within 30 days as very low, consistent with the absence of public weaponization and the niche attack surface.
CISA KEV StatusNot listed as of 2026-10-28.
CVSS VectorsCVSS 4.0: 9.5 Critical — 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 (CNA: TianoCore). CVSSv3: 8.8 High (Red Hat). The AT:P (Attack Prerequisites Present) in CVSS 4.0 partially captures the PXE-boot-active requirement, but AV:N overstates reachability — practical exploitation requires L2 adjacency, not internet-facing access.
Affected VersionsAll TianoCore EDK2 releases ≤ edk2-stable202608. Downstream: RHEL 8/9/10 edk2 packages, SUSE, Debian, Ubuntu OVMF packages, and all OEM firmware derived from EDK2 NetworkPkg. Microsoft Project Mu (hardened EDK2 fork) also affected — backport in mu_basecore PR #1989.
Fixed VersionsUpstream: commits merged in PR #13302 (2026-10-15), expected in edk2-stable202611. Red Hat: RHSA-2026:18465 for RHEL 10; RHEL 8/9 advisories pending. Distro backports are rolling out. OEM firmware updates depend on individual vendor timelines — none confirmed yet from Dell, HPE, Lenovo, or Supermicro.
Scanning / Exposure DataNo Shodan/Censys/FOFA exposure data applicable — PXE boot traffic is internal/L2 only and not internet-scannable. The attack surface is limited to hosts on provisioning/management VLANs during active PXE boot cycles.
Disclosure TimelineReserved 2026-09-24 by TianoCore CNA. AMI prematurely published fix code in late September. GHSA-99cj-7hg9-mp4m published. Official disclosure 2026-10-22. Original coordinated disclosure target was January 2027.
ResearchersAlex Matrosov (Anthropic, formerly Binarly CEO — deep UEFI security expertise) and Dan Holmes (Google). Both are established firmware security researchers with track records in UEFI vulnerability discovery.

Sources.

  1. GitHub PR #13302 — Upstream Fix (tianocore/edk2)
  2. GHSA-99cj-7hg9-mp4m — GitHub Security Advisory
  3. Strix.ai — CVE-2026-97631 CVSS and CWE Details
  4. Slashdot — Code-Execution Flaw In UEFI Firmware Threatens Most Servers
  5. SSBCrack News — Network Boot Vulnerability Scope Analysis
  6. Microsoft mu_basecore PR #1989 — Backport for Project Mu
  7. TuxCare — CVE-2026-97631 Tracker
  8. Offseq Radar — CVE-2026-97631 Threat Intel
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • L2 adjacency requirement negates AV:N scoring. The CVSS vector marks this as Network-reachable, but practical exploitation requires the attacker to be on the same L2 segment as the PXE-booting host — typically a dedicated provisioning VLAN. This is an internal-network, post-initial-access position for any external threat actor. Adjusting from the CNA's 9.5 baseline downward.
  • Temporal constraint severely limits the attack window. The vulnerable code path only executes during active PXE boot — a window of seconds to minutes that occurs almost exclusively during server provisioning or reimaging. Production servers boot from local disk. For a 10,000-host fleet, perhaps 0.1–1% are PXE booting at any given time. This compounding friction narrows the reachable population dramatically.
  • No persistence without chaining. The initial code execution is single-shot. Converting it to a persistent implant requires SPI flash write capability, which modern platforms with Intel Boot Guard or AMD PSB may block. This limits the blast radius of a single successful exploitation.
  • No public PoC and zero ITW exploitation. As of 2026-10-28, no weaponized tooling exists. EPSS at 0.43% corroborates low near-term exploitation probability. The fix diff provides a blueprint but crafting a reliable exploit across diverse OEM firmware builds is non-trivial.
  • Role multiplier: hypervisor hosts (ESXi, Hyper-V). These PXE-boot during deployment. Successful exploitation yields code execution *below the hypervisor* — all guest VMs on that host are compromised. Blast radius: host → tenant → potentially fleet-scale if provisioning network is shared. This role represents ~10–15% of enterprise server installs and confirms the HIGH floor.
  • Role multiplier: domain controllers and identity infrastructure. DCs are frequently PXE-provisioned. Pre-OS compromise of a DC = compromise of the identity trust root → domain-scale blast radius. However, DCs are provisioned infrequently and provisioning VLANs for DCs are typically the most tightly controlled. Floor confirmation: HIGH.
  • Role multiplier: bare-metal database and backup servers. High-value data tier hosts PXE-boot during deployment. Compromise yields access below the OS to all data at rest. Blast radius: data-scale. Provisioning frequency is low but impact per-host is severe.

Why not higher?

CRITICAL would require the attack to be reliably reachable without significant preconditions. Here, the attacker needs (1) L2 network position on a provisioning VLAN — itself requiring prior compromise or physical access, (2) a target that is actively PXE booting — a rare event in production, and (3) firmware-specific exploit tuning across diverse OEM builds. The combination of these three compounding prerequisites makes mass exploitation implausible. No PoC exists, no ITW exploitation has been observed, and EPSS at 0.43% validates the low near-term weaponization risk. The temporal constraint alone (PXE boot window) prevents this from being an at-will attack.

Why not lower?

EDK2 is the canonical UEFI firmware for virtually all enterprise servers — the bug is in the foundational firmware layer beneath hypervisors, operating systems, and all software-based security controls. When the chain does succeed, the outcome is ring -2 code execution, completely bypassing Secure Boot, TPM, EDR, and OS hardening. On high-value roles (hypervisor hosts, domain controllers, database servers) — which represent ≥10% of the installed base — the blast radius is fleet-scale or domain-scale. MEDIUM would understate the catastrophic *impact* dimension and would fail the deployment-role floor test.

06 · Verification

Crowdsourced verification payload.

Run this script on each target Linux host (bare-metal or VM) as root. It checks the installed edk2 package version (for OVMF/AAVMF virtual firmware) and the system BIOS version via dmidecode. Example: sudo bash check_cve_2026_97631.sh. For bare-metal hosts, the script identifies the BIOS vendor and version but cannot definitively confirm vulnerability status without OEM-specific version mappings — it flags these as UNKNOWN with guidance.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_97631.sh — CVE-2026-97631 EDK2 PXE ICMP Buffer Overflow checker
# Run as root on target Linux host. Checks edk2 package version and BIOS info.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'

echo "=== CVE-2026-97631 EDK2 PXE ICMP Buffer Overflow Check ==="
echo "Date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "Host: $(hostname -f 2>/dev/null || hostname)"
echo ""

VULN_STATUS="UNKNOWN"

# Check 1: Is PXE boot likely enabled? (check EFI variables if available)
if [ -d /sys/firmware/efi ]; then
    echo "[INFO] UEFI firmware detected."
else
    echo "[INFO] Legacy BIOS or no EFI sysfs — may not use EDK2 PXE stack."
fi

# Check 2: edk2 / OVMF package version (virtual machines)
EDK2_PKG=""
if command -v rpm &>/dev/null; then
    EDK2_PKG=$(rpm -qa 'edk2*' 2>/dev/null | head -5)
elif command -v dpkg &>/dev/null; then
    EDK2_PKG=$(dpkg -l 'ovmf*' 'qemu-efi*' 'edk2*' 2>/dev/null | grep '^ii' | awk '{print $2"-"$3}' | head -5)
fi

if [ -n "$EDK2_PKG" ]; then
    echo "[INFO] Installed edk2/OVMF packages:"
    echo "$EDK2_PKG" | while read -r pkg; do echo "       $pkg"; done
    # Check for known-patched versions
    # RHEL 10: edk2-20251114-5.el10_2 or later is patched for other CVEs;
    # CVE-2026-97631 fix expected in future advisory
    # Upstream fix: edk2-stable202611+
    if echo "$EDK2_PKG" | grep -qiE 'stable2026(09|10|11|12)|stable2027|20261[0-9]'; then
        echo -e "${YELLOW}[CHECK] Package version may include the fix — verify against vendor advisory.${NC}"
        VULN_STATUS="UNKNOWN"
    elif echo "$EDK2_PKG" | grep -qiE 'stable202[0-5]|stable20260[1-8]|2022|2023|2024|2025'; then
        echo -e "${RED}[VULNERABLE] edk2 package version predates the fix (edk2-stable202608 or earlier).${NC}"
        VULN_STATUS="VULNERABLE"
    else
        echo -e "${YELLOW}[UNKNOWN] Cannot determine patch status from package version.${NC}"
    fi
else
    echo "[INFO] No edk2/OVMF package installed (expected on bare-metal hosts)."
fi

echo ""

# Check 3: BIOS/firmware version via dmidecode (bare-metal)
if command -v dmidecode &>/dev/null; then
    BIOS_VENDOR=$(dmidecode -s bios-vendor 2>/dev/null || echo "unknown")
    BIOS_VERSION=$(dmidecode -s bios-version 2>/dev/null || echo "unknown")
    BIOS_DATE=$(dmidecode -s bios-release-date 2>/dev/null || echo "unknown")
    echo "[INFO] BIOS Vendor:  $BIOS_VENDOR"
    echo "[INFO] BIOS Version: $BIOS_VERSION"
    echo "[INFO] BIOS Date:    $BIOS_DATE"
    # Heuristic: BIOS dated before 2026-10-15 (fix merge date) likely vulnerable
    if [ "$BIOS_DATE" != "unknown" ]; then
        BIOS_EPOCH=$(date -d "$BIOS_DATE" +%s 2>/dev/null || echo "0")
        FIX_EPOCH=$(date -d "2026-10-15" +%s)
        if [ "$BIOS_EPOCH" -gt 0 ] && [ "$BIOS_EPOCH" -lt "$FIX_EPOCH" ]; then
            echo -e "${RED}[LIKELY VULNERABLE] BIOS date predates upstream fix (2026-10-15).${NC}"
            if [ "$VULN_STATUS" != "VULNERABLE" ]; then VULN_STATUS="VULNERABLE"; fi
        elif [ "$BIOS_EPOCH" -ge "$FIX_EPOCH" ]; then
            echo -e "${YELLOW}[INFO] BIOS date is after fix merge — check with OEM for confirmation.${NC}"
        fi
    fi
else
    echo "[WARN] dmidecode not available — cannot check BIOS version. Install dmidecode."
fi

echo ""

# Check 4: Is PXE/network boot in the current boot order? (best-effort)
if command -v efibootmgr &>/dev/null; then
    PXE_ENTRIES=$(efibootmgr -v 2>/dev/null | grep -iE 'pxe|network|ipv[46]|uefi.*nic' || true)
    if [ -n "$PXE_ENTRIES" ]; then
        echo "[WARN] PXE/Network boot entries found in UEFI boot manager:"
        echo "$PXE_ENTRIES" | while read -r line; do echo "       $line"; done
        BOOT_ORDER=$(efibootmgr 2>/dev/null | grep 'BootOrder' || true)
        echo "       Current boot order: $BOOT_ORDER"
        echo -e "${YELLOW}[ACTION] Consider disabling PXE boot entries if not actively provisioning.${NC}"
    else
        echo -e "${GREEN}[GOOD] No PXE/Network boot entries found in UEFI boot manager.${NC}"
        if [ "$VULN_STATUS" = "VULNERABLE" ]; then
            echo "[NOTE] PXE not in boot order — attack surface is reduced but firmware is still unpatched."
        fi
    fi
else
    echo "[INFO] efibootmgr not available — cannot check boot order."
fi

echo ""
echo "=== RESULT ==="
case "$VULN_STATUS" in
    VULNERABLE)
        echo -e "${RED}VULNERABLE — EDK2 firmware/package predates CVE-2026-97631 fix.${NC}"
        echo "Action: Disable PXE boot if not needed. Apply edk2 package or OEM firmware update."
        exit 1
        ;;
    PATCHED)
        echo -e "${GREEN}PATCHED — EDK2 firmware/package includes CVE-2026-97631 fix.${NC}"
        exit 0
        ;;
    *)
        echo -e "${YELLOW}UNKNOWN — Could not definitively determine patch status.${NC}"
        echo "Action: Check OEM firmware advisory for your BIOS vendor/version."
        echo "        Disable PXE boot as a precaution if not actively provisioning."
        exit 2
        ;;
esac