UEFI-Lücke CVE-2026-97631 (EDK II, PXE): Sofortmaßnahmen für Hetzner-Server und eigene Hardware

Wir behalten solche Meldungen für betreute Systeme im Blick. Im CVE-Monitoring bewerten wir neue Schwachstellen für Ihre Software und Hardware, im Server-Audit erfassen wir, welche Systeme im UEFI-Modus laufen und wo Neustarts anstehen. Server-Audit ansehen · Erstgespräch buchen (unverbindlich und kostenlos)

Seit dem 28. Oktober 2026 warnt Hetzner auf der Statusseite vor CVE-2026-97631, einer kritischen Lücke in der UEFI-Firmware EDK II (CVSS 9,5). Betroffen ist der Boot über das Netzwerk per PXE, nicht der laufende Betrieb. Diese Seite fasst zusammen, was belegt ist, was Hetzner empfiehlt und welche Schritte Sie heute gehen können, solange es keinen Firmware-Patch gibt. Stand: 29. Oktober 2026.

Inhaltsverzeichnis

• Kurz beantwortet
• Sofortmaßnahmen: die Checkliste
• Die Schwachstelle im Detail
• Wer betroffen ist
• Patch-Stand
• Wenn ein Neustart nötig ist
• Zeitleiste
• Verbreitete Fehlannahmen
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Kurz beantwortet

Sofortmaßnahmen: die Checkliste

Die Reihenfolge ist so gewählt, dass die ersten Schritte ohne Eingriff in den Betrieb gehen.

1. Prüfen, ob ein System im UEFI-Modus läuft. Der Befehl stammt von Hetzner: [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS. Nur Systeme mit der Ausgabe UEFI nennt Hetzner als betroffen.
2. Bestandsliste erstellen. Je Server: UEFI oder BIOS, Dedicated oder Cloud, ob der Bootpfad PXE nutzt, ob in den nächsten Tagen ein Neustart ansteht.
3. Geplante Neustarts zurückstellen. Wartungsfenster, Kernel-Updates mit Reboot und Hardware-Arbeiten verschieben, soweit das fachlich vertretbar ist. Hetzner rät, diese Bootvorgänge zu vermeiden, bis es eine Lösung gibt.
4. Rescue-Starts bei Cloud-VMs vermeiden. Bei Cloud-VMs besteht das Risiko nach Hetzner nur beim Start in das Rescue System.
5. Automatische Neustarts erfassen. Watchdog, HA-Fencing, automatische Updates mit Reboot und Skripte, die Server neu starten. Wo der Bootpfad PXE nutzt, für die Dauer abschalten (unsere Einschätzung).
6. Firewall-Regel vorbereiten. Wenn ein Neustart unvermeidbar ist, eingehendes ICMP in der Hetzner Firewall blockieren (Details im Abschnitt Wenn ein Neustart nötig ist).
7. Quellen beobachten. Hetzner-Statusseite, Sicherheitsübersichten der eingesetzten Distribution (Paket edk2 beziehungsweise ovmf), BIOS- und UEFI-Updates der Hardware-Hersteller.
8. Patch einspielen, sobald verfügbar. Bei Linux-Hosts über das Paket der Distribution, bei Bare Metal über das Firmware-Update des Herstellers, danach Neustart und Stand prüfen.

Die Schwachstelle im Detail

Laut Advisory des EDK-II-Projekts (veröffentlicht am 22. Oktober 2026) hält der PXE-Base-Code-Treiber einen Empfangsauftrag für ICMP-Fehlermeldungen offen und kopiert jede empfangene Meldung in das feste Feld Mode.IcmpError mit 504 Byte in seiner privaten Kontextstruktur.

Die Grenzprüfung ist sowohl im IPv4-Handler (PxeBcIcmpErrorDpcHandle) als auch im IPv6-Handler (PxeBcIcmp6ErrorDpcHandle) fehlerhaft: Bei Meldungen über 504 Byte wird weiter kopiert, und der Zielzeiger rückt um die kumulative statt um die Fragmentlänge vor. Daraus entsteht ein Schreibzugriff außerhalb des Puffers.

Eine dauerhafte Codeausführung ist damit nicht belegt. Das Advisory beschreibt die Ausführung in der DXE-Phase der Firmware, also vor dem Betriebssystem. Was ein Angreifer daraus macht, nennt es nicht.

Wer betroffen ist

Hetzner nennt zwei Gruppen, wenn sie mit UEFI laufen:

• Dedicated Server (Bare Metal): Das Risiko besteht nur während eines Neustarts.
• Cloud-VMs: Das Risiko besteht nur beim Start in das Rescue System.

Andere Umgebungen. EDK II ist die Grundlage vieler UEFI-Firmware, unter anderem von OVMF für virtuelle Maschinen unter KVM. Ob ein konkretes System die betroffene Komponente enthält und PXE im Bootpfad nutzt, hängt vom Firmware-Build und der Konfiguration ab. Dazu liegen uns außer den Angaben von Hetzner und den Distributionsübersichten keine Herstellererklärungen vor. Bis dahin gilt: Hersteller oder Hoster fragen, nicht annehmen.

Als betroffen nennt Hetzner nur Systeme im UEFI-Modus. Systeme im BIOS-Modus und laufende Systeme außerhalb des Boots nennt Hetzner nicht als gefährdet.

Patch-Stand

Die Korrektur im master-Zweig bedeutet nicht, dass Ihre Firmware sie enthält. Distributionen müssen sie in ihre Pakete übernehmen, Hardware-Hersteller in ihre BIOS-Images. Termine dafür sind bislang nicht angekündigt.

Wenn ein Neustart nötig ist

Hetzner empfiehlt als zusätzliche Maßnahme, eingehende ICMP-Pakete in der Hetzner Firewall vorübergehend zu blockieren, solange ein Neustart läuft. Der Angriff nutzt ICMP-Fehlermeldungen, die an das startende System geschickt werden.

• Dedicated Server: Firewall in der Robot-Oberfläche anlegen. Beim Anlegen der Regeln „Allow Hetzner Services“ aktivieren; Hetzner weist ausdrücklich darauf hin.
• Cloud-Server: Cloud Firewall ohne Inbound-Regel für ICMP erstellen und dem Server zuweisen; nicht freigegebener Verkehr wird verworfen. Hat der Server schon eine Firewall mit ICMP-Freigabe, diese Freigabe vorübergehend entfernen.

Ablauf in der Praxis: Regel anlegen, Neustart durchführen, Dienst prüfen, Regel wieder entfernen. Unsere Einschätzung: Solange ICMP gesperrt ist, funktionieren Ping und Path-MTU-Discovery nicht, deshalb nur für die Dauer des Neustarts. Die Regel mindert das Risiko, ersetzt aber keinen Patch. Bei Dedicated Servern gilt eine belegte Grenze: Laut Hetzner-Dokumentation lässt sich ICMPv6 nicht filtern und ist immer erlaubt, und die Firewall filtert standardmäßig nur IPv4. Da das Advisory PXE über IPv4 und IPv6 nennt, wirkt die Sperre dort nur für IPv4. Ob sie weitere Angriffswege abdeckt, etwa aus demselben Netzsegment, nennt weder Hetzner noch das Advisory.

Zeitleiste

Verbreitete Fehlannahmen

• „Alle meine Server sind jetzt angreifbar.“ Nein. Nach Hetzner besteht das Risiko nur beim Boot über das Netzwerk, nicht im laufenden Betrieb.
• „Secure Boot schützt mich.“ Nein. Die Schwachstelle wird ausgenutzt, bevor Secure Boot greift.
• „Es gibt einen Patch, also bin ich sicher.“ Die Korrektur steht im Quellcode. Pakete und Firmware-Updates, die Sie einspielen können, gibt es noch nicht.
• „Das betrifft nur Hetzner.“ Hetzner informiert, die Komponente ist aber nicht auf Hetzner beschränkt.
• „Ein Neustart ist jetzt verboten.“ Nein. Er ist mit Vorsicht zu planen und, wenn nötig, mit der ICMP-Sperre abzusichern.

Stand und Methodik

Stand: 29. Oktober 2026. Grundlage sind das Advisory und der Pull Request des EDK-II-Projekts, die Hetzner-Statusseite, die Sicherheitsübersichten von Debian und Ubuntu sowie Hetzners Dokumentation zur Firewall. Aussagen zu Hetzner stammen von Hetzner, die zur Fehlerart und zum Angreifer aus dem Advisory. Eigene Einschätzungen sind im Text als solche gekennzeichnet. Das Advisory ist zum Zeitpunkt der Prüfung nicht in der NVD ausgewertet; Schweregrad und Vektor stammen aus dem Advisory selbst. Wir aktualisieren den Beitrag, sobald Hetzner, Distributionen oder Hersteller Korrekturen oder Firmware-Updates veröffentlichen.

Unser Vorgehen bei WZ-IT

Bei betreuten Systemen gehen wir bei einer solchen Meldung in dieser Reihenfolge vor:

1. Bestand erfassen: UEFI oder BIOS, Dedicated, Cloud oder virtuell, Bootpfad, geplante Neustarts.
2. Neustarts bewerten: nötige Reboots einplanen, andere zurückstellen, automatische Neustarts erfassen.
3. Schutz setzen: für unvermeidbare Neustarts die ICMP-Sperre in der Firewall anlegen und danach wieder entfernen.
4. Beobachten: Hersteller, Distributionen und Hoster auf Firmware-Updates prüfen.
5. Patchen und verifizieren: Updates einspielen, neu starten, Stand dokumentieren.

Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level. Mehr zu Betrieb und Überwachung: Managed Operations für Hetzner, CVE-Monitoring und Proxmox-Betreuung.

Unsicher, welche Ihrer Server im UEFI-Modus laufen und wann Neustarts anstehen? Im Server-Audit erfassen wir Ihre Systeme, den Bootpfad und die geplanten Neustarts. Sie erhalten eine Liste mit Maßnahmen. Server-Audit ansehen · Erstgespräch buchen (unverbindlich und kostenlos)

Weiterführende Guides

• Warum Unternehmen CVE-Monitoring brauchen
• PHP2Shell: CVE-2026-109618, betroffene Software und Maßnahmen
• Nextcloud Built-in CODE Server: Command Injection ohne Login (CVE-2026-110447)
• Managed Operations für Hetzner
• CVE-Monitoring

Quellen

• 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 für Dedicated Server
• Hetzner Docs: Cloud Firewall erstellen
• Debian Security Tracker: CVE-2026-97631
• Ubuntu Security: CVE-2026-97631