Critical EDK II Vulnerability Puts PXE-Booting Systems at Risk

A critical security vulnerability in TianoCore's EDK II firmware framework could allow attackers to execute malicious code before a computer's operating system starts. The flaw, tracked as CVE-2026-97631, has received a CVSS 4.0 severity score of 9.5 out of 10.

The vulnerability affects the PXE network boot driver, which helps computers start from a network instead of relying on a local storage device. Under specific conditions, an unauthenticated attacker who can deliver specially crafted ICMP error messages to a vulnerable system during network boot could exploit a memory corruption issue and potentially execute code in the firmware environment.

The timing makes this issue particularly concerning. Because the attack occurs before the operating system loads, operating-system security controls have not yet taken over. Secure Boot and measured boot also cannot prevent the vulnerable firmware code from being exploited before those mechanisms verify or measure operating-system components. 

However, this does not mean every server or computer is vulnerable. Exposure depends on the firmware implementation, the affected driver and whether the system enters the vulnerable network-boot process.

How the EDK II PXE Vulnerability Works

The issue lies in NetworkPkg/UefiPxeBcDxe, the PXE Base Code driver included in EDK II. The component handles network-related operations during the pre-boot process.

According to TianoCore's security advisory, the driver copies incoming ICMP error-message data into a fixed-size buffer of 504 bytes. Its bounds-checking logic does not correctly prevent oversized messages from writing beyond that buffer.

The problem affects the driver's IPv4 and IPv6 ICMP error-handling routines. Incorrect pointer handling can cause attacker-controlled data to overwrite memory outside the intended destination.

If a vulnerable machine is performing a PXE boot when a specially crafted ICMP error message arrives, the resulting memory corruption could disrupt the boot process or potentially enable code execution during the firmware's DXE phase.

This phase runs before the operating system and handles important firmware operations, making successful exploitation a serious security concern. 

Why This Vulnerability Is Different From a Typical Software Flaw

Many security vulnerabilities target applications or operating-system components that start after a computer has completed its boot process. CVE-2026-97631 affects an earlier stage.

Firmware operates beneath the operating system and helps initialize hardware before handing control to the boot loader. An attacker who successfully exploits a flaw at this level may operate before many familiar software-based security protections become active.

The vulnerability is particularly relevant to organizations that rely on network booting for server deployment, operating-system provisioning or recovery.

That said, successful exploitation is not guaranteed simply because a device uses EDK II. The attacker must reach the vulnerable system during the PXE boot window, and achieving reliable code execution may require knowledge of the target firmware build.

The official advisory describes both a potential denial-of-service outcome and a path to arbitrary code execution under the relevant conditions. 

Which Systems Could Be Affected?

The vulnerability is associated with the EDK II NetworkPkg PXE driver. Firmware products that incorporate the affected code may therefore require investigation.

Potentially relevant environments include:

• Servers that use PXE to boot or provision operating systems.
• Enterprise systems that rely on EDK II-based UEFI firmware.
• Virtual machine firmware and related environments that incorporate affected EDK II components.
• Infrastructure appliances that use network booting for deployment or recovery.

The presence of EDK II alone does not establish that a particular product is vulnerable. Manufacturers can modify the reference implementation, omit affected functionality or provide their own firmware updates.

TianoCore's advisory identifies EDK II master as of September 14, 2026, as affected. Its upstream code change was merged through pull request #13302 on October 15, 2026. However, a merged upstream fix is not the same as a released BIOS update for every manufacturer or device. 

What Vendors Say About the Security Risk

The status of affected products must be assessed individually.

Intel has stated, according to reporting by Ars Technica, that its currently supported commercial products are not known to be affected. However, manufacturers may independently incorporate firmware components, so this statement should not be treated as a blanket assurance for every product that uses EDK II.

Other firmware vendors and hardware manufacturers need to establish whether their products contain the affected driver and whether a security update is necessary.

As of October 28, 2026, the available advisories do not establish that every potentially affected product has been patched. System administrators should follow updates from their specific hardware vendors rather than assume their systems are either vulnerable or protected.

The upstream EDK II fix provides a reference for remediation, but organizations should verify whether an applicable firmware release is available for their hardware. 

How to Protect Your Servers From CVE-2026-97631

Organizations that use network booting should investigate their exposure and reduce unnecessary risk while waiting for applicable vendor guidance.

1. Inventory Systems That Use PXE Boot

Identify servers, workstations and appliances that use PXE for deployment, recovery or routine startup. Record the manufacturer, firmware version and relevant EDK II components wherever this information is available.

Prioritize systems that regularly boot over IPv4 or IPv6 from network infrastructure.

2. Check for Firmware Updates

Contact your server or motherboard manufacturer to determine whether your firmware contains the affected PXE driver. Ask for an explicit applicability statement and a BIOS or UEFI update incorporating the fix, if required.

Installing an upstream code change yourself is not a substitute for a validated firmware update on production hardware.

3. Disable Network Boot Where It Is Not Needed

If a device does not require PXE booting, consider disabling the feature in its firmware settings.

This reduces exposure to the specific attack window described in the advisory. Do not disable network boot on systems that depend on it for essential deployment or recovery workflows without planning an alternative.

4. Isolate Provisioning Networks

Restrict access to network-boot infrastructure and management interfaces. Where practical, place provisioning systems on dedicated network segments and apply suitable filtering to traffic reaching machines during PXE boot.

These controls can reduce the opportunity for an attacker to reach the vulnerable driver, although they are not a replacement for a firmware fix.

5. Keep Secure Boot and Other Protections Enabled

Secure Boot and TPM-based measured boot remain important defenses against other threats. Continue using them alongside appropriate firmware updates, network segmentation and monitoring.

However, neither mechanism should be considered a complete defense against this particular pre-boot memory-corruption vulnerability.

6. Monitor Vendor Advisories and Security Logs

Track updates from TianoCore, your hardware manufacturer and your operating-system distributor. Preserve relevant provisioning and network logs so that unusual boot failures or suspicious activity can be investigated.

These measures can help teams respond quickly as more information about product-specific exposure and remediation becomes available.

Is CVE-2026-97631 Being Exploited in the Wild?

The vulnerability's technical impact is serious, but severity alone does not prove that attackers are actively exploiting it.

The available reporting around the initial disclosure did not establish confirmed widespread exploitation in the wild. Organizations should nevertheless avoid treating the absence of confirmed attacks as evidence that their systems are safe.

The most useful immediate steps are to identify systems that rely on PXE booting, verify whether the affected firmware component is present and follow the relevant manufacturer's remediation guidance.

Final Thoughts

CVE-2026-97631 highlights an important aspect of cybersecurity: vulnerabilities can exist in the firmware that starts a computer before the operating system has an opportunity to defend itself.

The EDK II PXE driver flaw can cause memory corruption and, under specific conditions, potentially enable code execution during network boot. Its critical severity makes it an important issue for server administrators and organizations that rely on network-based provisioning.

The priority is to verify exposure, restrict unnecessary PXE access and install a vendor-approved firmware update when one becomes available. Not every device is affected, but systems that depend on the vulnerable driver should not be overlooked simply because their operating systems are fully patched.