A newly disclosed firmware flaw is drawing attention because it targets code that runs before the operating system and most security software have started. The UEFI vulnerability CVE-2026-97631 affects a network-boot driver in the widely used TianoCore EDK II codebase and could, under the required conditions, allow an attacker to corrupt firmware memory and execute malicious code during the boot process.
The vulnerability was published on October 22, 2026. The official TianoCore advisory assigns it a CVSS 4.0 score of 9.5, or Critical. That rating reflects the potentially severe technical impact, but it does not mean every UEFI device, server, or EDK II-derived firmware build is exploitable. Exposure depends on the firmware components included by a manufacturer, platform configuration, patch status, and whether the vulnerable network-boot path is used or reachable.
What administrators need to know
- Affected component: The UefiPxeBcDxe PXE Base Code driver in EDK II’s NetworkPkg.
- Underlying problem: Improper bounds handling can cause an out-of-bounds write when the driver processes a crafted ICMP error message.
- Potential result: Firmware memory corruption, boot disruption, or arbitrary code execution in the pre-boot environment.
- Primary exposure: Systems whose firmware contains the affected driver and that use or expose the relevant PXE network-boot functionality.
- Recommended action: Identify affected platforms, request vendor-specific guidance, reduce network exposure, and install validated firmware updates when available.
How the EDK II vulnerability works
EDK II is an open-source implementation of the Unified Extensible Firmware Interface, better known as UEFI. Hardware and firmware companies use EDK II as a reference codebase and may incorporate portions of it into firmware for servers, storage appliances, workstations, and other systems.
According to the official TianoCore EDK II security advisory, CVE-2026-97631 exists in UefiPxeBcDxe, a driver that provides PXE Base Code services. During network boot, this driver can receive Internet Control Message Protocol, or ICMP, error messages.
The vulnerable code copies information from a received ICMP error into a fixed-size field named Mode.IcmpError. That destination is 504 bytes long, but the driver does not correctly enforce the relevant buffer-size limit. A specially constructed packet can therefore cause data to be written beyond the end of the field.
This out-of-bounds write may overwrite adjacent firmware memory. At a minimum, that could cause a crash or interfere with booting. With suitable control over the corrupted memory and the surrounding execution state, an attacker could potentially achieve arbitrary pre-boot code execution. The exact exploitability of a particular machine will depend on its firmware build, memory layout, configuration, and network conditions.
What PXE boot means in plain English
Most computers start by loading an operating system from a local SSD or another installed storage device. PXE, short for Preboot Execution Environment, provides another option: the machine connects to a network and downloads the resources it needs to begin booting.
Organizations use PXE and related network-boot workflows to provision servers, deploy operating-system images, recover machines, automate data center operations, and manage fleets of workstations. The capability is especially useful when administrators need to configure many systems consistently without handling each one individually.
Because the vulnerable code is involved in this process, CVE-2026-97631 should not be described as a universal flaw in every UEFI computer. A system generally must contain the affected implementation and encounter the malicious network input while the relevant driver is active. A laptop with EDK II-derived code but no reachable or enabled PXE workflow, for example, does not necessarily have the same exposure as a server configured to boot from an accessible provisioning network.
Why pre-boot code execution is especially serious
Firmware executes before the operating system loads. At that stage, endpoint detection software, host firewalls, application controls, and many logging systems are not yet operating. Malicious activity in this environment can consequently be harder for conventional endpoint tools to observe than malware running as an ordinary operating-system process.
Secure Boot is intended to verify that trusted, properly signed components participate in the boot process. It is an important defense against unauthorized bootloaders and other tampering, but it is not a general-purpose memory-safety control for every firmware driver.
A vulnerability inside firmware’s own network-boot implementation can undermine assumptions about the integrity of the chain that runs before those verified components. That does not mean Secure Boot is disabled or completely defeated on every affected system. Rather, the flaw creates a potential opportunity to execute code earlier in the process, within a trusted firmware environment that Secure Boot ordinarily assumes is functioning correctly.
Which servers and devices may be affected?
The upstream advisory identifies EDK II versions through edk2-stable202608 as affected. It associates the remediation with upstream pull request 13302. Administrators should still check the advisory for subsequent release changes and, more importantly, confirm whether their platform vendor has incorporated the corrected code into a supported firmware package.
EDK II’s broad industry role makes the vulnerability relevant to multiple firmware ecosystems, but the upstream project’s reach should not be confused with proof that every downstream product contains the flaw. Manufacturers may select different modules, modify the reference code, disable features, add mitigations, or use another PXE implementation entirely.
Reporting from Ars Technica on October 27 said Intel found no commercial products under security support that were known to be affected. Arm reportedly said the issue was not directly applicable. Those vendor statements should not be extrapolated into guarantees covering every Intel-based or Arm-based device, since motherboard firmware and platform components may come from other suppliers.
An upstream patch also is not equivalent to a downloadable BIOS or UEFI update for every commercial server. Firmware vendors and device manufacturers must incorporate the change, validate it against their custom code, test it on individual platforms, and distribute an approved update through their support channels.
Disclosure timeline and current exploitation status
CVE-2026-97631 was discovered by Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google. The CVE and official advisory were published on October 22, 2026, with the advisory assigning the flaw a Critical CVSS 4.0 score of 9.5.
Ars Technica reported that the intended coordinated-disclosure process was disrupted after vulnerability details and a fix appeared in a public pull request associated with AMI. Public exposure of technical details can shorten the time defenders have to prepare, although it does not by itself prove that attackers have successfully exploited the flaw.
As of the reporting surrounding disclosure, the public information established a serious technical path to memory corruption and possible code execution. It did not establish widespread compromise, an active ransomware campaign, or confirmed exploitation across server fleets. Organizations should prioritize remediation based on the severity and location of the flaw without treating unverified attack claims as fact.
Potential consequences for affected systems
A successful attack could have several outcomes, depending on the attacker’s level of control and the affected firmware implementation:
- Crashing the PXE driver or preventing a system from booting normally.
- Executing malicious code before the operating system and endpoint defenses start.
- Interfering with boot resources or system initialization.
- Accessing or manipulating sensitive information available during the pre-boot process.
- Establishing a foothold that supports follow-on attacks against the operating system or network.
Persistence beyond a reboot should not be assumed automatically. Achieving persistent firmware compromise may require additional capabilities beyond exploiting the initial memory-corruption bug. Nevertheless, even temporary pre-boot execution can be highly consequential on systems that handle sensitive workloads.
How administrators should respond to CVE-2026-97631
- Inventory network-boot systems. Identify servers, storage devices, appliances, and managed workstations that use PXE or another network-boot process. Include recovery and provisioning workflows that may be activated only during maintenance.
- Collect platform details. Record the firmware vendor, server or motherboard model, UEFI version, baseboard management controller version, and current configuration. Determine whether the firmware includes the affected EDK II UefiPxeBcDxe driver where possible.
- Check official vendor guidance. Review manufacturer security advisories and support portals for CVE-2026-97631. If documentation is unclear, ask the vendor for an explicit assessment covering the exact model and firmware version.
- Apply vendor-provided firmware updates. Install the validated BIOS or UEFI update as soon as operationally feasible. A generic operating-system patch does not repair vulnerable firmware code.
- Track systems awaiting remediation. Document affected or potentially affected assets, vendor case numbers, compensating controls, update availability, and planned maintenance dates.
Reduce exposure while waiting for updates
If network boot is not required, organizations can consider temporarily disabling PXE or network boot in firmware settings. That decision should follow normal change-control procedures and account for recovery, provisioning, and remote-management requirements.
Where PXE is essential, restrict access to provisioning networks and pre-boot interfaces. Separate network-boot infrastructure from untrusted user and public networks, limit which systems can send traffic into those segments, and monitor for unexpected devices or unusual activity. Review whether server interfaces attempt network boot unnecessarily before falling back to local storage.
Segmentation can reduce the opportunities available to an attacker, but it is a mitigation rather than a substitute for firmware remediation. Network controls can be misconfigured or bypassed, and trusted provisioning segments can themselves become compromised.
Why server firmware updates take time
Firmware patching is often more complicated than deploying an application or operating-system update. Packages may be specific to a hardware revision, require a reboot, affect remote-management controllers, or introduce compatibility concerns involving storage, networking, virtualization, and attached devices.
Large organizations may need maintenance windows, staged testing, coordinated fleet deployment, and a verified rollback or recovery procedure. Teams should also confirm that remote console access works before beginning and validate Secure Boot, boot order, PXE behavior, and production workloads afterward.
These operational challenges justify careful testing, not indefinite delay. Because a pre-boot compromise may leave fewer traces in conventional endpoint telemetry, accurate firmware inventory and direct coordination with vendors are particularly important.
Frequently asked questions
Is every UEFI system vulnerable to CVE-2026-97631?
No. Exposure depends on whether the system’s firmware contains the affected EDK II PXE driver, whether the vulnerable code remains unpatched, and whether the relevant network-boot path can receive attacker-controlled input. Vendors must assess their specific firmware builds.
Does Secure Boot prevent exploitation?
Secure Boot verifies trusted boot components, but the vulnerability is in firmware code that can execute before normal operating-system protections are active. Secure Boot may remain enabled while the vulnerable network-boot driver is exposed. The flaw should therefore be addressed through firmware remediation and appropriate network controls.
Can an operating-system security update fix the flaw?
No. CVE-2026-97631 affects UEFI firmware, not an operating-system PXE client. Administrators need a firmware update supplied or approved by the system, motherboard, or firmware vendor.
Should organizations disable PXE immediately?
Disabling PXE can reduce exposure where network boot is unnecessary, but it may interrupt provisioning or disaster-recovery processes. Organizations should evaluate operational dependencies, obtain change approval, and use network restrictions where the function must remain available.
Firmware visibility is the central lesson
CVE-2026-97631 demonstrates why firmware must be included in vulnerability-management programs. The EDK II flaw has serious potential because it affects code running at a highly trusted, difficult-to-monitor stage, but actual risk varies by product and configuration.
Administrators should avoid both extremes: assuming every server is compromised or assuming an upstream fix has already protected every device. The practical response is to inventory network-boot exposure, obtain explicit assessments from manufacturers, apply validated server firmware updates, and use segmentation only as an interim layer of defense.
