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.
5 steps from start to impact.
Attain L2 network position on provisioning VLAN
- 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
- 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
Wait for or trigger a PXE boot event
- Target has PXE boot enabled in UEFI firmware (default on most enterprise servers)
- Target is actively performing a PXE boot cycle
- 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
Send crafted oversized ICMP error response
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.- Ability to send raw ICMP packets to the target during PXE boot
- Knowledge of the buffer overflow trigger (publicly available from the fix commit)
- 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
Achieve pre-OS arbitrary code execution
- Successful heap overflow with controlled write primitive
- Compatible memory layout on the target's specific firmware build
- 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
Chain to persistent pre-boot implant (optional escalation)
- SPI flash write protection disabled or bypassable
- Knowledge of target firmware's SPI layout
- Sufficient execution time before OS handoff
- 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
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.- 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.
The supporting signals.
| In-the-Wild Exploitation | None 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 Availability | No 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 Score | 0.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 Status | Not listed as of 2026-10-28. |
| CVSS Vectors | CVSS 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 Versions | All 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 Versions | Upstream: 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 Data | No 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 Timeline | Reserved 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. |
| Researchers | Alex 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.
- GitHub PR #13302 — Upstream Fix (tianocore/edk2)
- GHSA-99cj-7hg9-mp4m — GitHub Security Advisory
- Strix.ai — CVE-2026-97631 CVSS and CWE Details
- Slashdot — Code-Execution Flaw In UEFI Firmware Threatens Most Servers
- SSBCrack News — Network Boot Vulnerability Scope Analysis
- Microsoft mu_basecore PR #1989 — Backport for Project Mu
- TuxCare — CVE-2026-97631 Tracker
- Offseq Radar — CVE-2026-97631 Threat Intel
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.
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.
#!/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