Code vor Secure Boot: Was die UEFI-Lücke im PXE-Netzwerkstart für Serverbetreiber bedeutet

Seit dem 22. Oktober 2026 ist eine kritische Schwachstelle in EDK II öffentlich, dem Open-Source-Grundgerüst, aus dem die meisten Hersteller ihre UEFI-Firmware bauen. Ein einzelnes, zu großes ICMP-Fehlerpaket reicht aus, um einen Rechner während des Netzwerkstarts zum Stillstand zu bringen – und wer den genauen Firmware-Stand des Ziels kennt, kann eigenen Code ausführen, bevor Secure Boot oder das TPM überhaupt etwas prüfen. Die Lücke trägt die Kennung CVE-2026-97631 und ist mit 9,5 von 10 Punkten nach CVSS 4.0 bewertet. Firmware-Updates der Gerätehersteller gibt es bislang nicht, der Fehler steckt seit rund 16 Jahren im Code.

Für die meisten Umgebungen ist das keine Panikmeldung, sondern eine Prüfaufgabe: Betroffen ist ausschließlich der Moment, in dem ein Gerät per PXE über das Netzwerk startet. Wer PXE nicht nutzt, ist über diesen Weg nicht angreifbar. Wer es nutzt – für Betriebssysteminstallation, Thin Clients oder Wiederherstellung – sollte jetzt wissen, wo und wie.

Was passiert ist

Warum die Lücke technisch bemerkenswert ist

Beim Netzwerkstart hält der PXE-Treiber eine Empfangsanfrage für ICMP-Fehlermeldungen offen – das sind die Pakete, mit denen Router oder Server melden, dass etwa ein Ziel nicht erreichbar ist. Jede eingehende Meldung kopiert der Treiber in ein festes Feld von 504 Byte in seiner privaten Datenstruktur. Die Kopierschleife prüft die Länge nicht und rückt den Schreibzeiger außerdem um die Gesamtlänge statt um die Länge des jeweiligen Fragments vor. Eine Meldung über 504 Byte schreibt deshalb vom Angreifer kontrollierte Bytes hinter das Feld. Laut Advisory begrenzt nichts auf dem Empfangsweg die Paketgröße vorab.

Zwei Folgen sind möglich. Erstens ein deterministischer Absturz: Die Daten des Treibers werden beschädigt, die nächste ICMP-Meldung löst eine CPU-Ausnahme im DXE-Kern aus – der Phase, in der die Firmware ihre eigenen Treiber lädt – und der Boot bleibt hängen. Ein Angreifer kann damit jede Netzwerkinstallation oder Wiederherstellung blockieren, ohne das Ziel im Detail zu kennen. Zweitens Codeausführung: Wer den exakten Firmware-Build kennt, kann laut TianoCore im selben Paket ein gefälschtes Ereignis unterbringen, das die Firmware anschließend als Code ausführt – mit Ring-0-Rechten, bevor ein Betriebssystem oder eine Sicherheitsfunktion existiert.

Das Muster ist nicht neu. Im Januar 2024 bündelte PixieFail neun Schwachstellen im Netzwerkstack von EDK II, damals vor allem in DHCPv6 und IPv6. CVE-2026-97631 betrifft einen anderen Code-Pfad – die ICMP-Fehlerbehandlung – in IPv4 wie IPv6. Die Lehre ist dieselbe: Der Netzwerkstack einer Firmware ist Angriffsfläche, bevor irgendeine Schutzschicht aktiv ist.

Wer betroffen ist – und wer nicht

Was Betreiber jetzt prüfen sollten

1. Inventur: Wo wird PXE tatsächlich genutzt? Deployment-Server (WDS, MDT, SCCM/MECM, FOG, Linux-PXE), Thin-Client-Pools, Notfall-Boot-Images, Hypervisor-Hosts. Auf Geräten, die es nicht brauchen, PXE im Firmware-Setup abschalten und den Netzwerk-Boot aus der Bootreihenfolge entfernen – nicht nur nach hinten sortieren.
2. Segmentierung des Provisioning-Netzes: PXE-Clients, DHCP- und TFTP-Server in ein eigenes VLAN legen, das nur aus dem Admin-Netz erreichbar ist. Entscheidend: Das Advisory nennt ausdrücklich, dass ein geroutetes Unicast-ICMP-Paket genügt. Die Firewall-Richtlinie muss also unaufgeforderte ICMP-Fehlermeldungen aus anderen Netzen in Richtung des Provisioning-Segments blockieren.
3. ICMP gezielt filtern, nicht pauschal: ICMP-Fehlertypen (Destination Unreachable, Time Exceeded, Parameter Problem) aus fremden Quellen Richtung PXE-Clients verwerfen; Fragmentierung über die Grenze des Segments hinweg unterbinden. Pauschales ICMP-Blocking stört Path-MTU-Discovery und ist keine Lösung.
4. Hersteller-Updates nach CVE-Nummer verfolgen: Firmware-Korrekturen kommen von Dell, HPE, Lenovo, Supermicro, Fujitsu und den Mainboard-Herstellern, nicht über Windows Update oder die Linux-Paketverwaltung. Auf den Support-Seiten gezielt nach CVE-2026-97631 suchen. Für Linux-Hosts mit QEMU/Proxmox: edk2- und ovmf-Pakete im Blick behalten.
5. Boot-Störungen ernst nehmen: Hängende PXE-Installationen oder Thin Clients, die beim Netzwerkstart stehen bleiben, waren bisher ein Netzwerkproblem. Ab jetzt gehören sie als möglicher Angriffsversuch in die Vorfallsdokumentation – mit Zeitpunkt, Gerät und Netzsegment.
6. Wiederherstellungspläne prüfen: Wer im Notfall per PXE neu installiert, sollte eine Alternative über USB-Medien oder ISO-Mount am Management-Controller (iDRAC, iLO, BMC) vorhalten. Ein Angreifer, der die Netzwerkinstallation blockieren kann, blockiert sonst auch die Wiederherstellung nach einem Vorfall.

Einordnung

Vier Punkte nehmen wir aus diesem Fall mit.

• Firmware ist eine eigene Patch-Disziplin. Betriebssystem-Updates laufen bei den meisten Organisationen automatisiert, Firmware-Updates nicht. Diese Lücke lässt sich ausschließlich über BIOS-/UEFI-Updates der Gerätehersteller schließen – und das Advisory nennt noch nicht einmal eine korrigierte Version. Wer kein Inventar mit Firmware-Ständen pflegt, kann die Frage „Sind wir betroffen?“ nicht beantworten.
• Der Leak zeigt, wie fragil koordinierte Offenlegung ist. Ein öffentlicher Pull Request mit CVE-Nummer und Fix, Wochen vor dem vereinbarten Termin – damit hatten Angreifer den Bauplan, bevor ein einziger Hersteller ein Update liefern konnte. Für Betreiber heißt das: Die Zeit zwischen Bekanntwerden und verfügbarem Patch muss über Netzwerkarchitektur überbrückt werden, nicht über Warten.
• Secure Boot ist kein Allheilmittel. Wir haben in diesem Jahr viel über den Zertifikatswechsel für Secure Boot geschrieben – zu Recht. Aber die Prüfkette ist nur so vertrauenswürdig wie der Code, der sie startet. Ein Netzwerkstack in der Firmware, der vor jeder Prüfung Pakete entgegennimmt, gehört in die Risikobewertung.
• PXE ist in Kommunen und im Mittelstand verbreiteter als gedacht. Nicht als Rechenzentrumstechnik, sondern als bequemer Weg, Arbeitsplätze neu aufzusetzen. Oft ist der Netzwerk-Boot auf allen Clients aktiv, weil es beim Rollout praktisch war. Genau diese Bequemlichkeit ist jetzt die Angriffsfläche – und sie lässt sich mit zwei Einstellungen pro Gerät schließen.

Quellen & weiterführende Links

• heise online

  UEFI-Lücke: Kritischer Bug versteckt sich seit 16 Jahren in vielen Servern (29.10.2026) – Anlass dieses Beitrags
• TianoCore (GitHub)

  GHSA-99cj-7hg9-mp4m – Pre-boot RCE in EDK II PXE driver (22.10.2026)
• TianoCore (GitHub)

  Pull Request #13302 – Korrektur im PXE-Treiber, gemerged am 15.10.2026
• Debian Security Tracker

  CVE-2026-97631 – Status der edk2-Pakete
• Rescana

  EDK II UEFI PXE Flaw CVE-2026-97631: Zeitleiste der Offenlegung
• Security Affairs

  CVE-2026-97631: 16-Year-Old UEFI Flaw Threatens Servers (29.10.2026)