Inhalt (6 Abschnitte)
Am 22. Oktober hat TianoCore eine Sicherheitsmeldung zu EDK II veröffentlicht, dem quelloffenen Code, auf dem die UEFI-Firmware der meisten Server und PCs aufbaut. Die Lücke, CVE-2026-97631, ist mit 9,5 von 10 bewertet. Sie steckt im Treiber für den Netzwerkstart, PXE. Ein Angreifer kann seinen Code während des Starts ausführen lassen, vor dem Betriebssystem und vor Secure Boot. Sechs Tage später hat noch kein großer Hersteller einen Patch für alle seine Modelle geliefert. Was auf dem Spiel steht, wer wirklich betroffen ist und was bis dahin zu tun ist.
Eine Lücke im allerersten Moment #
Startet ein Server über das Netzwerk, hört seine Firmware auf eingehende Nachrichten, darunter ICMP-Fehlermeldungen, also Meldungen wie „Host nicht erreichbar“. Der PXE-Treiber von EDK II kopiert sie in einen Bereich von 504 Byte. Laut der Meldung prüft er ihre Größe falsch, bei IPv4 wie bei IPv6: Eine längere Nachricht läuft über diesen Bereich hinaus und überschreibt den Speicher daneben.
TianoCore beschreibt zwei Folgen. Die einfachere: Der Start bleibt hängen. Die schwerere: Ein Angreifer, der den genauen Firmware-Build des Ziels kennt, kann eigene Bytes in der Phase ausführen lassen, in der die Firmware die Maschine vorbereitet, mit allen Rechten. Er braucht weder Konto noch Passwort: Es genügt, eine ICMP-Fehlermeldung an die IP-Adresse der Maschine zu schicken, während sie startet, und laut der Meldung geht das aus jeder Entfernung im Netz.
Ernst wird es durch den Zeitpunkt. Secure Boot prüft den Bootloader des Systems. Virenschutz, die Firewall der Maschine und ihre Protokolle kommen noch später. Hier passiert alles vorher. Code, der sich auf dieser Ebene einnistet, kann eine komplette Neuinstallation des Systems überstehen.
Veröffentlicht vor den Patches #
Der Ablauf erklärt, warum Patches fehlen. Ein erster Änderungsantrag, der die Lücke nennt, erscheint am 28. September öffentlich im Repository von EDK II. Die Korrektur wird am 15. Oktober in den Code übernommen, die Meldung folgt am 22. Laut Thomas-Krenn war die Veröffentlichung für Anfang 2027 geplant und hätte nicht so früh geschehen sollen.
Eine Korrektur in EDK II schützt aber niemanden direkt. Sie muss erst zu den Firmware-Anbietern (AMI, Insyde, Phoenix), dann zu jedem Mainboard- und Serverhersteller, Board für Board, bevor sie als BIOS-Update ankommt. Supermicro hat begonnen, korrigierte Versionen für einige X12- und X13-Serien zu veröffentlichen. Microsoft hat die Korrektur am 28. Oktober in Project Mu übernommen. Bei den meisten anderen heißt es noch warten.
Bei virtuellen Maschinen sieht es etwas besser aus. Fedora hat seit dem 26. Oktober korrigierte Pakete im Test, NixOS hat die Korrektur übernommen, Red Hat arbeitet nach eigenen Angaben daran. Zum Zeitpunkt dieses Artikels führen Debian und SUSE das Paket als verwundbar, ohne Patch.
Wer wirklich betroffen ist #
Die Lücke betrifft nur eine Maschine, die über das Netzwerk startet, und nur während dieses Starts. Ein laufender Server ist auf diesem Weg nicht angreifbar. Ein Server, der direkt von seiner Festplatte startet, ohne Umweg über das Netz, ebenso wenig. Drei Situationen verdienen dennoch Aufmerksamkeit.
Erstens dedizierte Server bei einem Hoster. Damit sich ein Rettungssystem aus der Ferne starten lässt, versuchen viele dedizierte Server bei jedem Einschalten zuerst einen Netzwerkstart, vor der Festplatte. Hetzner hat am 28. Oktober einen Vorfall eröffnet: Bei dedizierten Servern besteht das Risiko bei jedem Neustart, bei Cloud-Maschinen beim Start des Rettungssystems. Hetzner rät, Neustarts bis zum Patch zu vermeiden und während unvermeidlicher Neustarts eingehendes ICMP in seiner Netzwerk-Firewall zu sperren.
Zweitens virtuelle Maschinen mit UEFI. Unter Proxmox, QEMU oder KVM heißt die UEFI-Firmware einer virtuellen Maschine OVMF, und OVMF baut auf EDK II auf. Eine VM mit ihrer Netzwerkkarte in der Bootreihenfolge kann also den verwundbaren Treiber durchlaufen: wenn die Karte vor der Festplatte steht oder wenn die Festplatte nicht startet und die Firmware auf das Netz ausweicht. VMs mit SeaBIOS, der anderen Firmware von Proxmox, sind von dieser Lücke nicht betroffen. Der Hypervisor selbst ist nur über seine eigene Firmware angreifbar, wie jeder physische Server.
Drittens Umgebungen, die über das Netz installiert werden: per PXE ausgerollte Arbeitsplätze und Server, Schulungsräume, Maschinen, die aus Gewohnheit über das Netz starten. Dort öffnet sich das Fenster bei jedem Start.
Was bis zum Patch zu tun ist #
Klären Sie zuerst, welche Maschinen im UEFI-Modus starten. Unter Linux verrät es das Verzeichnis /sys/firmware/efi. Prüfen Sie dann im BIOS oder in der Management-Konsole jedes Servers, ob der Netzwerkstart aktiv ist und wo er in der Bootreihenfolge steht. Wo er nichts nützt, schalten Sie ihn ab. Wo er gebraucht wird, setzen Sie ihn hinter die Festplatte.
Unter Proxmox beantworten zwei Zeilen der VM-Konfiguration die Frage: qm config <id> | grep -E '^(bios|boot):'. Läuft die VM mit ovmf und steht ihre Netzwerkkarte, etwa net0, in der Bootreihenfolge, entfernen Sie sie, wenn sie nicht gebraucht wird, zum Beispiel mit qm set <id> --boot order=scsi0. Behalten Sie das CD-ROM-Laufwerk, falls nötig. Die Proxmox-Firewall kann zusätzlich ICMP zu den VMs filtern, die einen Netzwerkstart behalten müssen.
Verkleinern Sie dann die Fenster. Verschieben Sie Neustarts, die nicht drängen, und sperren Sie für die übrigen eingehendes ICMP vorgelagert für die Dauer des Starts, danach stellen Sie die Regel zurück. Bei Hetzner sollten Sie in der Regel die Hetzner-Dienste zulassen, sonst funktionieren das Rettungssystem und die Überwachung des Hosters nicht mehr.
Bereiten Sie schließlich den Patch vor. Für physische Server verfolgen Sie die Meldungen Ihres Herstellers (Dell, HPE, Lenovo, Supermicro…): Das Update kommt über das BIOS, und Secure Boot erspart es Ihnen nicht. Für VMs kommt der Patch über das OVMF-Firmwarepaket des Hypervisors, unter Proxmox pve-edk2-firmware. Ist dieses Paket aktualisiert, lädt eine VM die neue Firmware erst nach vollständigem Herunterfahren und erneutem Start: Ein einfacher Neustart aus der VM heraus genügt nicht.
Was diese Lücke über Hosting sagt #
Diese Lücke lässt sich nicht mit einem Update-Befehl an einem Abend schließen. Man muss wissen, wie jede Maschine startet, vorgelagert filtern, den Zeitpunkt der Neustarts wählen und dann Patches verfolgen, die über Wochen Hersteller für Hersteller eintreffen. Das ist Inventur und Geduld, kein Reflex.
Für die Server, die wir hosten und betreuen, gehört diese Arbeit zur Behandlung der Warnung: Bootreihenfolge von Servern und VMs geprüft, Netzwerkstart entfernt, wo er nichts nützt, Neustarts hinter vorgelagerter Filterung geplant, dann Firmware aktualisiert, sobald Hersteller und Proxmox ihre Patches liefern.
Werden Ihre Server oder Ihr Proxmox-Cluster anderswo betreut, oder wissen Sie nicht, welche davon über das Netz starten? Wir gehen es gern mit Ihnen durch: welche Maschinen betroffen sind, was sofort einzustellen ist und wie der Patch eingespielt wird, wenn er kommt.
Quellen #
- TianoCore, Meldung GHSA-99cj-7hg9-mp4m, Pre-boot RCE in EDK II PXE driver (22. Oktober 2026, auf Englisch): Beschreibung, CVSS-4.0-Wert 9,5, Danksagungen.
- EDK II, Änderungsantrag 13200 (28. September 2026) und übernommene Korrektur, Antrag 13302 (15. Oktober 2026).
- Hetzner, Vorfall CVE-2026-97631 (eröffnet am 28. Oktober 2026): Risiko beim Neustart, Empfehlungen zur Firewall.
- Thomas-Krenn, Kritische PXE Boot Sicherheitslücke in EDK2 (aktualisiert am 30. Oktober 2026): vorzeitige Veröffentlichung, korrigierte Supermicro-BIOS-Versionen.
- Red Hat, Seite zu CVE-2026-97631 (auf Englisch).
- NixOS, übernommene Korrektur.
- IT-Connect, Faille UEFI EDK II : un paquet ICMP pour exécuter du code avant Secure Boot (28. Oktober 2026, auf Französisch).
