Ein Server soll nach einem Update neu starten. Die Betriebssystem-Patches sind geprüft, Secure Boot ist aktiviert, das Wartungsfenster steht. Trotzdem kann genau dieser Neustart eine zusätzliche Angriffsfläche öffnen: wenn der Rechner seine Startumgebung über das Netzwerk lädt und dabei verwundbare UEFI-Firmware verarbeitet.
Daraus ist am 28. Oktober ein konkretes Betriebsproblem geworden. Hetzner veröffentlichte um 18:08 Uhr MEZ eine Warnung zu CVE-2026-97631 und empfiehlt, Neustarts von Hosts mit PXE-Boot vorerst zu vermeiden. Laufende Systeme seien nicht unmittelbar durch diesen Fehler gefährdet. Die Analyse der eigenen Umgebung läuft noch. Das ist weder eine bestätigte Kompromittierung noch eine pauschale Warnung vor jedem Serverneustart. Es ist eine gezielte Vorsichtsmaßnahme für einen bestimmten Startpfad. [1]
Was neu ist – und was bereits bekannt war
Die Schwachstelle selbst wurde nicht gestern entdeckt. TianoCore veröffentlichte das Advisory am 22. Oktober; der Quellcode-Fix wurde bereits am 15. Oktober in den Entwicklungszweig übernommen. Neu sind die aktuelle Betreiberwarnung und ihre Konsequenz für Wartungs- und Wiederanlaufpläne. Ein vorhandener Entwicklungs-Patch und ein freigegebenes Firmware-Update für ein konkretes Servermodell sind unterschiedliche Dinge. [1][2][3]
Für Unternehmen lautet die erste Frage deshalb nicht: „Haben wir EDK II irgendwo im Inventar?“ Sie lautet: „Welche Systeme durchlaufen beim nächsten Start tatsächlich den betroffenen Netzwerkboot-Code, und wer kann ihnen währenddessen Pakete zustellen?“
Der Fehler sitzt vor dem Betriebssystem
EDK II ist eine Open-Source-Grundlage für UEFI-Firmware. Betroffen ist der PXE-Base-Code-Treiber NetworkPkg/UefiPxeBcDxe. Während eines Netzwerkstarts verarbeitet er ICMP-Fehlermeldungen über IPv4 und IPv6. Das Advisory beschreibt ein festes, 504 Byte großes Speicherfeld, in das empfangene Nachrichten kopiert werden. Die Größenprüfung und die Fortschreibung des Zielzeigers sind fehlerhaft; überlange Nachrichten können angrenzenden Speicher überschreiben. [2]
Ein nicht authentifizierter Angreifer benötigt dafür Netzwerkreichweite zum startenden Rechner. Als Auswirkungen nennt TianoCore einen hängenden Bootvorgang und, bei Kenntnis des konkreten Firmware-Builds, Codeausführung in der DXE-Phase. Entscheidend ist die Reihenfolge: Die Verarbeitung findet statt, bevor Betriebssystemkomponenten durch Secure Boot geprüft beziehungsweise durch Measured Boot vermessen wurden. Das ist kein Bruch der Signaturkryptografie, sondern ein Speicherfehler in einer früheren Verarbeitungsstufe. [2]
Der eingespielte Fix ergänzt Grenzprüfungen und korrigiert die Offset-Berechnung für beide IP-Versionen. Überlange Nachrichten werden auf die verfügbare Puffergröße begrenzt. Der Pull Request enthält außerdem Tests für fragmentierte Nachrichten, Abschneiden und die Integrität benachbarter Puffer. Laut Projekt schlagen die Tests vor der Änderung fehl und bestehen danach. Das belegt die beabsichtigte Reparatur im Projekt, nicht ihre Auslieferung auf einem bestimmten Mainboard. [3]
Warum eine CVSS-Zahl die Exposition nicht beschreibt
TianoCore bewertet die Lücke mit CVSS 4.0 als kritisch mit 9,5 Punkten. Red Hat nennt dagegen unter CVSS 3.1 vorläufig einen Wert von 8,8 und einen benachbarten Netzwerkangriffsvektor. Red Hat weist ausdrücklich darauf hin, dass Produkt- und Build-Eigenschaften zu abweichenden Bewertungen führen können. Die Zahlen sind deshalb nicht als einfache Rangliste derselben Einsatzsituation zu lesen. [2][4]
Für die betriebliche Prüfung folgt daraus: Weder pauschal offene Internet-Erreichbarkeit behaupten noch den Angriff ohne eigene Netzprüfung auf ein einzelnes VLAN begrenzen. Zu untersuchen sind tatsächliche Routing-, Filter- und Provisionierungswege während des Boots. Eine ausschließlich lokal startende Maschine und ein regelmäßig per Netzwerk neu provisionierter Host benötigen unterschiedliche Prioritäten.
Firmware ist auch ein Cloud- und Virtualisierungsthema
SUSE führt mehrere Produkte mit dem Quellpaket ovmf als betroffen, darunter SUSE Linux Enterprise Server 15 SP7 und 16.0 sowie openSUSE Leap 16.0. Die am 28. Oktober aktualisierte Seite verknüpft noch keine Sicherheitsankündigung. Das erweitert die Inventur über physische BIOS-Versionen hinaus auf ausgelieferte Firmware-Komponenten. Eine betroffene Paketzeile allein beweist allerdings noch keinen erreichbaren PXE-Pfad in jeder damit betriebenen VM. [5]
Die praktische Konsequenz: Infrastrukturteams sollten Hardware-Firmware, virtuelle Firmware und Provisionierungsdienste gemeinsam betrachten. Für einen Virtualisierungshost gehört die Frage nach den tatsächlich verwendeten Firmware-Dateien ebenso in die Prüfung wie die Bootkonfiguration der Gäste. Zuständigkeiten zwischen Betriebssystemteam, Plattformbetrieb, Hosting-Anbieter und Hardwarelieferant sollten nicht erst im Wartungsfenster geklärt werden.
Fünf konkrete Schritte für Unternehmen
1. Bootpfade statt nur Produktnamen inventarisieren. Erfasst werden sollten Firmware-Hersteller und Build, aktivierte Netzwerkboot-Optionen, Bootreihenfolge, einmalige Remote-Boot-Einstellungen und die verantwortliche Betriebsgruppe. Auch Installations- und Wiederherstellungsabläufe gehören dazu. Eine sinnvolle Ergebnisliste unterscheidet „PXE erforderlich“, „PXE unnötig“ und „noch ungeklärt“.
2. Neustarts gezielt freigeben. Für Hosts unter Hetzners Warnung sollte die dortige Empfehlung berücksichtigt werden. Daraus sollte kein unbefristeter allgemeiner Patchstopp entstehen. Empfehlenswert ist eine dokumentierte Einzelentscheidung: Welchen Bootpfad nimmt dieser Host, welche Schutzmaßnahme greift und welches Risiko entsteht durch Verschieben? Unvermeidbare Neustarts benötigen eine abgestimmte Vorgehensweise mit dem Betreiber. [1]
3. Provisionierung als Sicherheitszone behandeln. Wo PXE notwendig bleibt, sollten Teams die Erreichbarkeit während des Starts auf erforderliche Kommunikationspartner und Dienste begrenzen. IPv4 und IPv6 sind getrennt zu prüfen. Filteränderungen gehören zunächst in einen repräsentativen Testlauf; pauschales Blockieren sämtlicher ICMP-Nachrichten ist kein sorgfältig validierter Ersatz für eine Firmwarekorrektur.
4. Lieferanten nach einem konkreten Nachweis fragen. Die Anfrage sollte Modell, Firmwarestand und CVE enthalten. Benötigt werden eine Aussage zur Betroffenheit, die korrigierte Firmware oder Paketrevision und eine Anleitung zur Aktivierung. Ein Verweis auf den öffentlichen Pull Request reicht als Abschluss nicht aus. Für virtuelle Firmware ist zusätzlich zu klären, ob bestehende Instanzen die neue Datei tatsächlich verwenden.
5. Die Abnahme vorab definieren. Nach Verfügbarkeit eines freigegebenen Updates sollten Unternehmen Installation, aktiven Firmwarestand und den erforderlichen Netzwerkboot in einer kontrollierten Umgebung prüfen. Das Ergebnis gehört mit Datum und Verantwortlichem ins Änderungsticket. Ein erfolgreicher Betriebssystemstart allein beantwortet nicht, ob die richtige Firmware eingesetzt wurde.
Grenzen der aktuellen Erkenntnisse
Die ausgewerteten Primärquellen liefern keine belastbare Gesamtzahl betroffener Server und keine Grundlage, sämtliche UEFI-Systeme als kompromittiert zu bezeichnen. Das Advisory beschreibt eine technisch mögliche Codeausführung unter Voraussetzungen, keine universelle Angriffsgarantie. Hetzners Meldung ist eine Untersuchung mit Vorsichtsempfehlung, kein öffentlich bestätigter Angriff. [1][2]
Auch der Patchstatus muss präzise bleiben: Der Upstream-Fix ist vorhanden, während das Advisory weiterhin keine gepatchte Version ausweist. Betreiber müssen die konkrete Lieferkette bis zur installierbaren und aktivierten Firmware verfolgen. [2][3]
Fazit
CVE-2026-97631 macht den Netzwerkstart zu einer eigenen Sicherheitsentscheidung. Die sinnvolle Reaktion ist weder Panik noch ein pauschales Reboot-Verbot: Bootpfade erfassen, unnötige Netzwerkstarts abschalten, notwendige Provisionierung isolieren und Herstellerkorrekturen bis zur aktiven Firmware nachweisen. Gerade Wiederanlaufpläne sollten diese Grenze berücksichtigen, bevor der nächste Neustart ungeplant stattfindet.
Quellen
Stand: 29. Oktober 2026, frühe Morgenstunden MEZ.
