Global News | November 5, 2026
A vulnerability in the open-source EDK II firmware codebase could allow attackers to execute malicious code before an affected computer starts its operating system. Tracked as CVE-2026-97631, the flaw affects the Preboot Execution Environment (PXE) network-boot driver and carries a CVSS 4.0 score of 9.5 out of 10 in the TianoCore security advisory.
The vulnerability, described by researchers as a pre-boot remote code execution flaw, involves incorrect handling of Internet Control Message Protocol (ICMP) error messages. An attacker who can deliver a specially crafted message while a vulnerable system is performing a PXE network boot may trigger memory corruption in the firmware environment. Under certain conditions, this could result in arbitrary code execution before the operating system and its security controls are loaded.
The issue is significant because EDK II is an open-source development project used as a foundation for UEFI firmware in products from multiple hardware manufacturers. However, that does not mean every server or computer is vulnerable. Exposure depends on whether a device uses the affected firmware component and enters the vulnerable PXE network-boot process.
The UEFI firmware vulnerability was publicly documented by TianoCore on October 22, 2026. Since then, hardware and software vendors have published additional advisories identifying affected products, firmware versions and mitigation steps. Their disclosures also show why organizations need to check the exact firmware and platform they operate rather than assume that a general operating-system update will resolve the issue.
What Is CVE-2026-97631?
CVE-2026-97631 is a buffer-overflow vulnerability in the EDK II PXE Base Code driver, specifically the UefiPxeBcDxe component within the project’s NetworkPkg.
The driver is involved in network-based system startup. PXE allows a computer to obtain boot files from a network server instead of relying exclusively on a local storage device. Organizations commonly use this approach for operating-system deployment, remote provisioning, recovery and large-scale management of computers and servers.
According to TianoCore’s advisory, the affected code processes ICMP error messages received during PXE boot. It copies incoming message data into a fixed-size 504-byte field called Mode.IcmpError, which is part of the driver’s private context structure.
The problem is that the code does not correctly enforce the destination buffer’s size when handling oversized messages. The advisory identifies incorrect bounds handling in both the IPv4 and IPv6 processing routines.
The affected handlers are PxeBcIcmpErrorDpcHandle, which processes IPv4 ICMP error messages, and PxeBcIcmp6ErrorDpcHandle, which processes IPv6 ICMP error messages.
The incorrect copying logic can allow attacker-controlled data to be written beyond the allocated 504-byte field. This is an out-of-bounds write, a memory-safety failure that can corrupt adjacent data structures and disrupt the firmware’s execution.
TianoCore identifies the issue as affecting EDK II master as of September 14, 2026. Its advisory assigns the vulnerability a critical CVSS 4.0 score of 9.5 and credits Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google with discovering the issue and contributing to the recommended fix.
How the UEFI Firmware Vulnerability Affects PXE Boot
The vulnerability is associated with the period when a device is actively performing a PXE network boot. It is not described as a general remote attack against a computer that has already completed startup and is running its operating system normally.
During network boot, the PXE driver maintains a receive request for ICMP error messages. When a message arrives, the driver copies its contents into the fixed-size buffer. The vulnerability occurs because the code’s handling of message length and destination-pointer movement does not properly prevent data from extending beyond the buffer.
The issue affects both IPv4 and IPv6 processing paths. Consequently, changing from one IP version to the other does not, by itself, remove the underlying weakness.
TianoCore describes two possible outcomes.
The first is denial of service. Corrupted driver data can cause a CPU exception within the DXE core when the firmware processes a subsequent ICMP error message. This can interrupt startup and prevent the system from completing network boot. In environments that depend on PXE for provisioning or recovery, that could disrupt deployment operations.
The second, more serious outcome is arbitrary code execution during the firmware’s Driver Execution Environment (DXE) phase. TianoCore explains that an attacker who knows the target firmware build may be able to construct a packet that places a counterfeit event in the affected memory area. The firmware could then dispatch attacker-controlled data through CoreSignalEvent().
This is a particularly sensitive execution stage because the operating system has not yet started. Code executing at this point operates outside the normal protections provided by the running operating system.
The UEFI firmware vulnerability therefore creates a risk that is different from a conventional application or operating-system flaw: successful exploitation may occur before endpoint security software and other operating-system protections become active.
Why the Flaw Matters Before Secure Boot
UEFI is the firmware interface responsible for initializing hardware and preparing a computer to start an operating system. It operates before the operating system’s normal security environment.
Secure Boot is designed to verify the digital signatures of boot components before allowing them to execute. Measured Boot records measurements of components during startup so that later systems can assess whether the boot process followed an expected sequence.
However, TianoCore’s advisory specifically states that the vulnerable code can be reached before Secure Boot or measured boot has verified or measured any operating-system component.
This distinction matters. Secure Boot is not a universal defence against vulnerabilities in the firmware code that executes before the operating system’s boot components are checked. A flaw in that earlier stage can create an opportunity for an attacker to interfere with the startup process itself.
The same principle applies to operating-system security tools. Endpoint detection and response products, antivirus software and host-based monitoring generally depend on the operating system being available. They cannot be relied upon to prevent a firmware-level memory corruption event that occurs before those tools have started.
The UEFI firmware vulnerability does not mean Secure Boot is ineffective or that every system using it is compromised. It means organizations should not treat Secure Boot as a substitute for fixing vulnerable firmware.
Which Systems and Vendors Are Affected?
The underlying EDK II project is used in firmware development across a broad hardware ecosystem. That makes the vulnerability relevant to server manufacturers, motherboard vendors, firmware suppliers and organizations that deploy systems through network boot.
Nevertheless, the exact scope varies by product. A device must contain the affected implementation and be exposed to the vulnerable PXE boot process for the described attack to apply.
AMD
AMD published its security bulletin, AMD-SB-7081, on November 3, 2026. The company identifies the affected scope as AMD Zen processors using PXE boot.
AMD describes the issue as a pre-boot remote code execution vulnerability and assigns it a Medium severity rating in its own bulletin. It says TianoCore released an EDK II patch and recommends that customers contact their original equipment manufacturer (OEM) for a BIOS update specific to their product.
This rating differs from TianoCore’s CVSS 4.0 score of 9.5. The two assessments should not be treated as interchangeable: vendors can use different scoring approaches and assess their own product exposure differently.
Supermicro
Supermicro has published a security notice identifying affected Intel- and Ampere-based product families and listing BIOS firmware versions containing fixes.
Its advisory includes specific motherboard and platform families, with firmware versions such as 5.3a for several X13 products, 1.6 for listed A4 Amston Lake products and 2.1a for certain X14 systems. Other product families have their own version information.
These details are important because the availability of a fix depends on the exact hardware model. Administrators should consult Supermicro’s current security notice and the support page for their particular system before installing firmware.
Red Hat
Red Hat identifies the vulnerability in EDK2 and lists affected components in Red Hat Enterprise Linux 8, 9 and 10, as well as certain OpenShift environments.
Its advisory assigns a CVSS v3 score of 8.8. Red Hat also clarifies an important exposure condition: in its RHEL and OpenShift environments, the flaw is exposed during network-boot sequences when the PXE driver processes untrusted network packets before the operating system initializes.
Virtual machines that boot strictly from local storage, or systems operating in their normal post-boot runtime, are not exposed to this specific PXE-triggered attack path according to Red Hat’s statement.
At the time of the reviewed advisory, the listed affected packages did not show issued security errata. Administrators should check Red Hat’s live CVE page for subsequent changes and product-specific remediation.
Debian
Debian’s security tracker lists the edk2 source package as vulnerable in the Bookworm, Trixie, Forky and Sid release entries shown in its tracker.
The tracker references upstream EDK II commits associated with the fix but lists the Debian package as unfixed in the status information reviewed for this report. An upstream code correction does not automatically mean that a distribution has already integrated, tested and released it in its own packages.
Debian administrators should monitor the security tracker and the associated bug report for package-status changes before assuming that their installed package contains the correction.
Other Firmware Implementations
Because EDK II is a foundational codebase rather than a single retail product, the full list of affected systems cannot be determined simply by identifying a processor brand or server manufacturer.
Firmware vendors may integrate, modify or omit particular components. A product using UEFI is not automatically affected, and a system with an AMD, Intel or Arm processor should not be classified as vulnerable solely on that basis.
Organizations need confirmation from the manufacturer or firmware supplier about whether the affected PXE driver is present in their specific firmware build.
Patch Status and the Difference Between an Upstream Fix and a BIOS Update
TianoCore’s advisory points to pull request #13302 as the recommended correction. The associated upstream changes address the vulnerable handling of ICMP messages in the EDK II PXE driver.
However, the advisory’s patched-version field still stated that EDK II was not patched in a released version at the time of review, despite identifying the proposed correction. This distinction is important for organizations that build firmware from EDK II or rely on downstream products based on it.
A code correction in an upstream project is only one stage of the remediation process. Firmware manufacturers must determine whether their products contain the affected code, integrate the correction, test the resulting firmware and distribute an update through their support channels.
The vendor notices demonstrate that remediation is product-specific. Supermicro lists BIOS versions for identified products, while AMD directs customers to their OEMs for platform-specific updates. Red Hat and Debian maintain separate package and distribution status records.
The UEFI firmware vulnerability should therefore be tracked through the support channel that supplies the affected system’s firmware, not only through the upstream EDK II repository.
What Organizations Should Do Now
Organizations that use PXE boot for servers, workstations, virtualized infrastructure or recovery systems should review their exposure and remediation plans.
Organizations should first identify systems that use network boot. They should inventory servers and other devices configured to start through PXE, paying particular attention to provisioning networks, deployment environments, recovery infrastructure and systems that may enter network boot during maintenance.
They should then confirm the firmware implementation. This involves checking the system manufacturer, motherboard model, BIOS or UEFI version and whether the firmware includes the affected EDK II PXE driver. Administrators should not assume that every device using UEFI is affected.
The next step is to check manufacturer advisories. Organizations should review the relevant OEM security notices and support pages and install the BIOS or UEFI update approved for the exact system model when one is available. They should follow the manufacturer’s update instructions and change-management procedures.
Administrators using Red Hat, Debian or other distributions should also review the relevant security tracker and package advisories. An upstream fix or a public patch reference does not prove that a distribution’s installed package is already corrected.
Where network boot is not required, organizations can consider disabling it temporarily in firmware configuration. Where PXE is operationally necessary, they should restrict access to the relevant provisioning network and limit which systems can communicate with devices during the boot process. These measures reduce exposure but should not be treated as a replacement for a firmware update.
Organizations should also monitor firmware and provisioning activity. Reviewing network-boot infrastructure and relevant network security logs for unusual ICMP traffic or unexpected boot failures may help identify suspicious events that warrant investigation. Such activity is not proof of exploitation.
Finally, organizations should maintain a tested recovery plan. Firmware updates can affect low-level startup components. Administrators should follow vendor guidance, maintain appropriate backups and recovery procedures, and test updates on representative systems before broad deployment.
Is CVE-2026-97631 Being Exploited?
The public advisories and vendor information reviewed for this report describe the vulnerability, its technical impact and remediation guidance. They do not establish confirmed widespread exploitation in the wild.
The existence of a public technical advisory and an upstream correction can make vulnerability details more accessible to defenders and potential attackers alike. However, the publication of technical information should not be confused with evidence that attackers have successfully compromised production systems.
TianoCore’s description also makes clear that reliable code execution is more demanding than simply causing a system to encounter an oversized message. The advisory describes the need for an attacker to know the target firmware build to construct the event-related data used in the code-execution scenario. The more straightforward outcome described is corruption that can cause a boot failure.
Organizations should therefore treat the issue as a serious firmware exposure requiring timely remediation, while avoiding unsupported claims that all affected systems have been compromised or that a particular threat group is exploiting it.
A Firmware-Level Risk That Requires Product-Specific Action
CVE-2026-97631 highlights the security challenges associated with shared firmware components. An error in a foundational open-source project can affect products from different manufacturers, but each vendor must establish which of its systems contain the vulnerable implementation and deliver appropriate updates.
The most important practical distinction is the PXE boot condition. Systems that do not use the affected network-boot driver in the vulnerable process are not exposed through the attack path described by TianoCore. Conversely, organizations that rely on PXE for provisioning or recovery should not assume that normal operating-system security controls protect the earlier firmware stage.
The latest disclosures from AMD, Supermicro, Red Hat and Debian show that remediation is progressing through separate hardware and software channels. Administrators should verify their exact platform, follow the relevant vendor guidance and install a confirmed firmware or package update when available.
The UEFI firmware vulnerability is a reminder that securing a computer requires attention to the code that runs before the operating system—not only the software that operates after startup.
Conclusion
CVE-2026-97631 is a serious firmware-level vulnerability affecting the EDK II PXE network-boot driver. Under specific conditions, specially crafted ICMP error messages could cause memory corruption and potentially enable code execution before an affected system loads its operating system.
The issue is particularly relevant to organizations that rely on network boot for provisioning, recovery and system deployment. However, the vulnerability does not automatically affect every UEFI-based computer or server. Exposure depends on the firmware implementation and the use of the affected PXE boot process.
AMD, Supermicro, Red Hat and Debian have published information about affected products, package status or remediation. Organizations should use these advisories to identify their exposure and follow the update guidance for their specific hardware and software environments.
Source note: This report draws on the TianoCore EDK II security advisory, AMD’s security bulletin, Supermicro’s product security notice, Red Hat’s CVE information, Debian’s security tracker and reporting by WIRED and Ars Technica. Vendor severity ratings and remediation statuses are attributed to the respective organizations. The report does not treat all UEFI systems as affected or claim confirmed widespread exploitation.
NewsFlayer — Your trusted source for cybersecurity news, digital threats and technology developments.