Companies/Hetzner/Incidents

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

Timeline of updates

1. investigating2026-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 (opens in new tab)
   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.

2. investigating2026-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/ (opens in new tab)): 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/ (opens in new tab)
   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.

3. investigating2026-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/ (opens in new tab)): 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/ (opens in new tab)
   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.

4. investigating2026-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/ (opens in new tab)): 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/ (opens in new tab)
   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.

5. investigating2026-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/ (opens in new tab)): 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/ (opens in new tab)
   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.

6. investigating2026-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/ (opens in new tab)): 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/ (opens in new tab)
   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.

7. investigating2026-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.

8. investigating2026-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.

9. investigating2026-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.

10. investigating2026-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.

11. investigating2026-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.

12. investigating2026-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.

Changes Rewindex caught on this incident

• Oct 29Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component
• Oct 29Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component
• Oct 30Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component
• Nov 2Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component
• Nov 3Incident updated: CVE-2026-97631 - critical security vulnerability in the EDK II UEFI firmware component

Impact, status and times are the vendor’s own, as last archived. View on status.hetzner.com (opens in new tab).

Hetzner profileRecent Hetzner incidentsAll outages on October 28, 2026Hetzner in October 2026MarkdownJSON