# Hetzner: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component

> Hetzner status incident “CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component” on 2026-10-28: impact minor (vendor’s label), 12 update(s). Archived by Rewindex.

Canonical: https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17
Last updated: 2026-11-03T10:03:16Z

- Impact (vendor’s label): minor
- Status: investigating · edited after publishing
- Started: 2026-10-28 17:08 UTC · Resolved: not resolved · Duration: ongoing
- Updates: 12
- [Vendor status page: https://status.hetzner.com/incident/54493dac-b3a2-44f0-8d8b-6de8b25d8f17](https://status.hetzner.com/incident/54493dac-b3a2-44f0-8d8b-6de8b25d8f17)
- [Company: Hetzner](https://rewindex.com/company/hetzner.md)

## CVEs mentioned

- [CVE-2026-97631](https://rewindex.com/cve/CVE-2026-97631.md) Pre-boot RCE in EDK II PXE driver (CVSS 9.5 critical): names this CVE

_Only CVEs the incident text names by id, or that the notice says the vendor is not affected by. Not a statement of cause._

## Timeline of updates

- **investigating** 2026-10-28 17:08 UTC: Start: 2026-10-28T17:08:08+00:00 A critical security vulnerability has recently been identified in the EDK II UEFI firmware component (CVE-2026-97631, CVSS 9.5). Further details can be found in the advisory: https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m What is affected? The vulnerability affects systems that boot over the network using PXE. During the boot process, an attacker may be able to execute malicious code through specially crafted network packets, even before the operating system and its security mechanisms (e.g., Secure Boot) are active. Systems that are already running are not directly at risk; the vulnerability can only be exploited during a PXE boot. An official patch is not yet available. What do we recommend? As an immediate precautionary measure, we recommend avoiding reboots of your hosts until further notice if they use PXE boot. What happens next? We are currently analyzing the impact on our environment and developing further recommendations and additional protective measures. We will inform you promptly as soon as new findings or updates become available.
- **investigating** 2026-10-29 11:49 UTC: What is affected? Dedicated Servers (bare-metal servers) and Cloud VMs running with UEFI. On Linux, you can check this with the following command: \[ -d /sys/firmware/efi \] && echo UEFI \|\| echo BIOS What do we recommend? A running system is not directly at risk. For Dedicated Servers, the risk only exists during a reboot. For Cloud VMs, the risk only exists when booting into the Rescue System. If possible, avoid these boot processes until a solution is available. As an additional security measure, you can block incoming ICMP packets using the Hetzner Firewall: Dedicated Servers (https://docs.hetzner.com/robot/dedicated-server/firewall/): Please make sure to enable “Allow Hetzner Services” when creating the firewall rules. Cloud Servers: https://docs.hetzner.com/cloud/firewalls/getting-started/creating-a-firewall/ What happens next? We are working on further recommendations and additional security measures. We will inform you as soon as we have new information or updates.
- **investigating** 2026-10-29 12:34 UTC: What is affected? Dedicated Servers (bare-metal servers) and Cloud VMs running with UEFI. On Linux, you can check this with the following command: \[ -d /sys/firmware/efi \] && echo UEFI \|\| echo BIOS What do we recommend? A running system is not directly at risk. For Dedicated Servers, the risk only exists during a reboot. For Cloud VMs, the risk only exists when booting into the Rescue System. If possible, avoid these boot processes until a solution is available. As an additional security measure, you can temporarily block incoming ICMP packets using the Hetzner Firewall during reboots: Dedicated Servers (https://docs.hetzner.com/robot/dedicated-server/firewall/): Please make sure to enable “Allow Hetzner Services” when creating the firewall rules. Cloud Servers: https://docs.hetzner.com/cloud/firewalls/getting-started/creating-a-firewall/ What happens next? We are working on further recommendations and additional security measures. We will inform you as soon as we have new information or updates.
- **investigating** 2026-10-29 12:34 UTC: What is affected? Dedicated Servers (bare-metal servers) and Cloud VMs running with UEFI. On Linux, you can check this with the following command: \[ -d /sys/firmware/efi \] && echo UEFI \|\| echo BIOS What do we recommend? A running system is not directly at risk. For Dedicated Servers, the risk only exists during a reboot. For Cloud VMs, the risk only exists when booting into the Rescue System. If possible, avoid these boot processes until a solution is available. As an additional security measure, you can temporarily block incoming ICMP packets using the Hetzner Firewall during reboots: Dedicated Servers (https://docs.hetzner.com/robot/dedicated-server/firewall/): Please make sure to enable “Allow Hetzner Services” when creating the firewall rules. Cloud Servers: https://docs.hetzner.com/cloud/firewalls/getting-started/creating-a-firewall/ What happens next? We are working on further recommendations and additional security measures. We will inform you as soon as we have new information or updates.
- **investigating** 2026-10-29 12:34 UTC: What is affected? Dedicated Servers (bare-metal servers) and Cloud VMs running with UEFI. On Linux, you can check this with the following command: \[ -d /sys/firmware/efi \] && echo UEFI \|\| echo BIOS What do we recommend? A running system is not directly at risk. For Dedicated Servers, the risk only exists during a reboot. For Cloud VMs, the risk only exists when booting into the Rescue System. If possible, avoid these boot processes until a solution is available. As an additional security measure, you can temporarily block incoming ICMP packets using the Hetzner Firewall during reboots: Dedicated Servers (https://docs.hetzner.com/robot/dedicated-server/firewall/): Please make sure to enable “Allow Hetzner Services” when creating the firewall rules. Cloud Servers: https://docs.hetzner.com/cloud/firewalls/getting-started/creating-a-firewall/ What happens next? We are working on further recommendations and additional security measures. We will inform you as soon as we have new information or updates.
- **investigating** 2026-10-29 12:34 UTC: What is affected? Dedicated Servers (bare-metal servers) and Cloud VMs running with UEFI. On Linux, you can check this with the following command: \[ -d /sys/firmware/efi \] && echo UEFI \|\| echo BIOS What do we recommend? A running system is not directly at risk. For Dedicated Servers, the risk only exists during a reboot. For Cloud VMs, the risk only exists when booting into the Rescue System. If possible, avoid these boot processes until a solution is available. As an additional security measure, you can temporarily block incoming ICMP packets using the Hetzner Firewall during reboots: Dedicated Servers (https://docs.hetzner.com/robot/dedicated-server/firewall/): Please make sure to enable “Allow Hetzner Services” when creating the firewall rules. Cloud Servers: https://docs.hetzner.com/cloud/firewalls/getting-started/creating-a-firewall/ What happens next? We are working on further recommendations and additional security measures. We will inform you as soon as we have new information or updates.
- **investigating** 2026-10-30 16:07 UTC: We're implementing filters in our network, which will drop fragmented ICMPv4 packets, as well as ICMPv4 errors larger than 768 bytes. In particular: Any IPv4 packet with protocol ICMP and the "More Fragments (MF)" flag or non-zero "Fragment Offset" will be dropped. We will also drop any ICMPv4 packets that are of type 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), or 12 (Parameter Problem), when their IPv4 header has a "Total Length" \>= 768 bytes. Our previous recommendations on how to protect your systems still apply.
- **investigating** 2026-10-30 16:07 UTC: We're implementing filters in our network, which will drop fragmented ICMPv4 packets, as well as ICMPv4 errors larger than 768 bytes. In particular: Any IPv4 packet with protocol ICMP and the "More Fragments (MF)" flag or non-zero "Fragment Offset" will be dropped. We will also drop any ICMPv4 packets that are of type 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), or 12 (Parameter Problem), when their IPv4 header has a "Total Length" \>= 768 bytes. Our previous recommendations on how to protect your systems still apply.
- **investigating** 2026-10-30 16:07 UTC: We're implementing filters in our network, which will drop fragmented ICMPv4 packets, as well as ICMPv4 errors larger than 768 bytes. In particular: Any IPv4 packet with protocol ICMP and the "More Fragments (MF)" flag or non-zero "Fragment Offset" will be dropped. We will also drop any ICMPv4 packets that are of type 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), or 12 (Parameter Problem), when their IPv4 header has a "Total Length" \>= 768 bytes. Our previous recommendations on how to protect your systems still apply.
- **investigating** 2026-11-02 13:03 UTC: The network filters described in our last update are now active at our network edge and between our locations. We are completing the rollout of the filters on cloud servers today. For dedicated (BareMetal) servers, we are currently evaluating how to extend these protective measures further within our DC networks. Until then, our previous recommendations still apply, especially for dedicated servers: Please avoid reboots where possible, and if a reboot is necessary, temporarily block incoming ICMP packets using the Hetzner Firewall. We will keep you informed about further progress.
- **investigating** 2026-11-02 13:03 UTC: The network filters described in our last update are now active at our network edge and between our locations. We are completing the rollout of the filters on cloud servers today. For dedicated (BareMetal) servers, we are currently evaluating how to extend these protective measures further within our DC networks. Until then, our previous recommendations still apply, especially for dedicated servers: Please avoid reboots where possible, and if a reboot is necessary, temporarily block incoming ICMP packets using the Hetzner Firewall. We will keep you informed about further progress.
- **investigating** 2026-11-03 09:56 UTC: Network filters have already been in place for cloud servers for some time. These protective measures are now fully implemented across our Cloud infrastructure, resolving the issue for Cloud. For dedicated (bare-metal) servers, we are continuing to explore ways to further expand these protective measures within our data center networks.

## Rewindex changes for this incident

- 2026-10-29 11:53 UTC: [Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component](https://rewindex.com/change/rd6e4d86fd32334.md)
- 2026-10-29 12:43 UTC: [Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component](https://rewindex.com/change/r49bf1247b43caa.md)
- 2026-10-30 16:13 UTC: [Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component](https://rewindex.com/change/r93eb85d76d530d.md)
- 2026-11-02 13:13 UTC: [Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component](https://rewindex.com/change/r0b67f246d04dcd.md)
- 2026-11-03 10:03 UTC: [Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component](https://rewindex.com/change/r10115fbf4bb414.md)

## Cite this

Status incident (vendor impact label: minor) posted by Hetzner, started 2026-10-28 17:08 UTC, not resolved, 12 update(s); edited after publishing.

- Canonical URL: https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17
- Citation: Hetzner, “CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component” (2026-10-28 17:08 UTC). Archived by Rewindex: https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17 (CC BY 4.0).
- Markdown link: `[Hetzner: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component (2026-10-28)](https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17)`


---
Canonical: https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17 · Markdown: https://rewindex.com/company/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17.md · JSON: https://rewindex.com/api/v1/companies/hetzner/incidents/54493dac-b3a2-44f0-8d8b-6de8b25d8f17 · Data licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) · Generated 2026-11-04T13:17:35.961Z