UEFI vulnerability CVE-2026-97631 (EDK II, PXE): immediate measures for Hetzner servers and your own hardware

We keep an eye on notices like this for managed systems. In CVE monitoring we assess new vulnerabilities for your software and hardware, and in the server audit we record which systems run in UEFI mode and where reboots are due. View server audit · Book an intro call (free and non-binding)

Since 28 October 2026, Hetzner has been warning on its status page about CVE-2026-97631, a critical flaw in the EDK II UEFI firmware (CVSS 9.5). It concerns booting over the network with PXE, not running operation. This page summarises what is documented, what Hetzner recommends and which steps you can take today while no firmware patch exists. As of 29 October 2026.

Table of contents

• In brief
• Immediate measures: the checklist
• The vulnerability in detail
• Who is affected
• Patch status
• If a reboot is necessary
• Timeline
• Common misconceptions
• Status and methodology
• Our approach at WZ-IT
• Further guides

In brief

Immediate measures: the checklist

The order is chosen so that the first steps do not touch operation.

1. Check whether a system runs in UEFI mode. The command comes from Hetzner: [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS. Hetzner names only systems that print UEFI as affected.
2. Build an inventory. Per server: UEFI or BIOS, dedicated or cloud, whether the boot path uses PXE, whether a reboot is due in the next days.
3. Postpone planned reboots. Move maintenance windows, kernel updates with reboot and hardware work where this is professionally acceptable. Hetzner advises avoiding these boot processes until a solution is available.
4. Avoid Rescue System starts on cloud VMs. For cloud VMs, Hetzner says the risk exists only when booting into the Rescue System.
5. List automatic reboots. Watchdogs, HA fencing, automatic updates with reboot and scripts that restart servers. Where the boot path uses PXE, disable them for the duration (our assessment).
6. Prepare the firewall rule. If a reboot is unavoidable, block incoming ICMP in the Hetzner Firewall (details in the section If a reboot is necessary).
7. Watch the sources. Hetzner status page, security trackers of your distribution (package edk2 or ovmf), BIOS and UEFI updates from hardware vendors.
8. Apply the patch once available. On Linux hosts through the distribution package, on bare metal through the vendor's firmware update, then reboot and verify the state.

The vulnerability in detail

According to the advisory of the EDK II project (published on 22 October 2026), the PXE Base Code driver keeps a receive request for ICMP error messages open and copies every received message into the fixed 504-byte field Mode.IcmpError in its private context structure.

The bounds check is faulty in both the IPv4 handler (PxeBcIcmpErrorDpcHandle) and the IPv6 handler (PxeBcIcmp6ErrorDpcHandle): for messages above 504 bytes, copying continues and the destination pointer advances by the cumulative rather than the fragment length. This results in a write outside the buffer.

Persistent code execution is therefore not documented. The advisory describes execution in the DXE phase of the firmware, that is, before the operating system. What an attacker does with it, it does not say.

Who is affected

Hetzner names two groups when they run with UEFI:

• Dedicated servers (bare metal): The risk exists only during a reboot.
• Cloud VMs: The risk exists only when booting into the Rescue System.

Other environments. EDK II is the basis of much UEFI firmware, among others OVMF for virtual machines under KVM. Whether a specific system contains the affected component and uses PXE in its boot path depends on the firmware build and configuration. Apart from Hetzner's statements and the distribution trackers, we have no vendor statements on this. Until then: ask the vendor or hoster, do not assume.

Hetzner names only systems in UEFI mode as affected. It does not name systems in BIOS mode or running systems outside of boot as at risk.

Patch status

The fix in the master branch does not mean your firmware contains it. Distributions must take it into their packages and hardware vendors into their BIOS images. No dates for that have been announced so far.

If a reboot is necessary

Hetzner recommends as an additional measure to temporarily block incoming ICMP packets in the Hetzner Firewall while a reboot is running. The attack uses ICMP error messages sent to the booting system.

• Dedicated servers: Create a firewall in the Robot interface. When creating the rules, enable “Allow Hetzner Services”; Hetzner points this out explicitly.
• Cloud servers: Create a Cloud Firewall without an inbound rule for ICMP and assign it to the server; traffic that is not allowed is dropped. If the server already has a firewall that allows ICMP, temporarily remove that rule.

In practice: create the rule, perform the reboot, check the service, remove the rule again. Our assessment: while ICMP is blocked, ping and path MTU discovery do not work, so only for the duration of the reboot. The rule lowers the risk but does not replace a patch. For dedicated servers there is a documented limit: according to Hetzner's documentation ICMPv6 cannot be filtered and is always allowed, and the firewall filters only IPv4 by default. Since the advisory names PXE over IPv4 and IPv6, the block works there for IPv4 only. Whether it covers other attack paths, for example from the same network segment, is stated neither by Hetzner nor by the advisory.

Timeline

Common misconceptions

• “All my servers are attackable now.” No. According to Hetzner, the risk exists only when booting over the network, not during running operation.
• “Secure Boot protects me.” No. The flaw is exploited before Secure Boot takes effect.
• “There is a patch, so I am safe.” The fix is in the source code. Packages and firmware updates that you can install do not exist yet.
• “This only affects Hetzner.” Hetzner is informing its customers, but the component is not limited to Hetzner.
• “Rebooting is now forbidden.” No. Plan it with care and, where needed, secure it with the ICMP block.

Status and methodology

As of 29 October 2026. The basis is the advisory and the pull request of the EDK II project, the Hetzner status page, the security trackers of Debian and Ubuntu, and Hetzner's firewall documentation. Statements about Hetzner come from Hetzner, those about the type of flaw and the attacker from the advisory. Our own assessments are marked as such in the text. At the time of review the advisory was not yet analysed in the NVD; severity and vector come from the advisory itself. We update this article as soon as Hetzner, distributions or vendors publish corrections or firmware updates.

Our approach at WZ-IT

For managed systems we proceed in this order when such a notice appears:

1. Record the inventory: UEFI or BIOS, dedicated, cloud or virtual, boot path, planned reboots.
2. Assess reboots: schedule necessary ones, postpone others, list automatic reboots.
3. Put protection in place: for unavoidable reboots, create the ICMP block in the firewall and remove it afterwards.
4. Watch: check vendors, distributions and hosters for firmware updates.
5. Patch and verify: apply updates, reboot, document the state.

Monitoring runs 24/7, and the response to P1 incidents follows the service level. More on operations and monitoring: Managed operations for Hetzner, CVE monitoring and Proxmox support.

Unsure which of your servers run in UEFI mode and when reboots are due? In the server audit we record your systems, the boot path and the planned reboots. You receive a list of measures. View server audit · Book an intro call (free and non-binding)

Further guides

• Why companies need CVE monitoring
• PHP2Shell: CVE-2026-109618, affected software and measures
• Nextcloud built-in CODE Server: command injection without login (CVE-2026-110447)
• Managed operations for Hetzner
• CVE monitoring

Sources

• GitHub advisory GHSA-99cj-7hg9-mp4m: CVE-2026-97631, EDK II
• EDK II pull request 13302: Fix ICMP buffer overflow in IPv4/IPv6 handle
• Hetzner Status: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component
• Hetzner Docs: firewall for dedicated servers
• Hetzner Docs: creating a Cloud Firewall
• Debian Security Tracker: CVE-2026-97631
• Ubuntu Security: CVE-2026-97631