Im Open-Source-Projekt EDK II, auf dem ein großer Teil der heutigen UEFI-Firmware aufbaut, steckt eine kritische Sicherheitslücke. Die Schwachstelle CVE-2026-97631 sitzt im Treiber für den PXE-Netzwerkstart. Laut dem am 22. Oktober 2026 veröffentlichten Sicherheitshinweis von TianoCore kann ein Angreifer im Netz einen startenden Rechner zum Absturz bringen oder sogar eigenen Code ausführen, bevor Betriebssystem und Secure Boot überhaupt aktiv sind. Die Einstufung: CVSS 9,5 von 10. Die gute Nachricht für Privatanwender vorweg: Wer seinen PC ganz normal von SSD oder Festplatte startet, ist von diesem Angriffsweg nicht betroffen.
Was ist PXE – und wer nutzt das?
PXE (Preboot Execution Environment) erlaubt es einem Rechner, sein Betriebssystem nicht von einem lokalen Datenträger, sondern über das Netzwerk zu laden. Das ist im Rechenzentrum Alltag: Server werden so automatisch installiert, Arbeitsplatz-PCs in Unternehmen und Schulen per Netzwerk neu aufgesetzt, Thin Clients starten komplett ohne eigene Festplatte. Auch virtuelle Maschinen können per PXE booten.
Genau in diesem kurzen Zeitfenster – zwischen Einschalten und Laden des Betriebssystems – liegt das Problem. Die Firmware arbeitet dann in der sogenannten DXE-Phase mit höchsten Rechten, und es gibt noch keinen Virenscanner, keine Firewall und keine Prüfung durch Secure Boot.
Wie die Lücke funktioniert
Der betroffene Code liegt im Paket NetworkPkg, genauer im Treiber UefiPxeBcDxe. Während des Netzwerkstarts nimmt dieser Treiber ICMP-Fehlermeldungen entgegen und legt sie in einem fest vorgegebenen Speicherfeld von 504 Byte ab. Nach Angaben von TianoCore ist die Längenprüfung sowohl im IPv4- als auch im IPv6-Zweig fehlerhaft: Ist eine Meldung länger, wird trotzdem weiterkopiert, und zusätzlich wird der Zielzeiger falsch weitergeschoben. So landen vom Angreifer bestimmte Daten hinter dem Ende des Feldes im Speicher. Fachlich handelt es sich um einen klassischen Pufferüberlauf mit Schreibzugriff außerhalb der Grenzen (CWE-120, CWE-131, CWE-787).
TianoCore beschreibt zwei mögliche Folgen:
- Absturz: Schon eine zu lange ICMP-Fehlermeldung kann den Bootvorgang zuverlässig hängen lassen. Der Rechner lässt sich dann nicht mehr per Netzwerk installieren oder wiederherstellen.
- Codeausführung: Kennt der Angreifer den genauen Firmware-Stand des Zielsystems, kann er eigene Daten in der DXE-Phase ausführen lassen – also mit Ring-0-Rechten und bevor irgendein Schutzmechanismus des Betriebssystems existiert. Secure Boot und Measured Boot haben zu diesem Zeitpunkt noch nichts geprüft.
Der Angreifer braucht dafür weder Zugangsdaten noch eine Aktion des Nutzers. Er muss aber eine gezielt adressierte ICMP-Fehlermeldung an die IP-Adresse des Rechners schicken, und zwar genau während dieser beim Start per PXE auf Daten wartet.
Warum TianoCore und Red Hat unterschiedlich bewerten
Auffällig ist die abweichende Einstufung. TianoCore kommt nach CVSS 4.0 auf 9,5 (kritisch) und setzt als Angriffsvektor „Network“ an, also auch über größere Netzwerkdistanz. Red Hat bewertet die Lücke nach CVSS 3.1 mit 8,8 (hoch) und geht von einem Angreifer im benachbarten Netz aus. In der Praxis heißt das: Das größte Risiko besteht dort, wo ein Angreifer bereits Zugang zum internen Netz oder zum Bereitstellungs-VLAN hat. Red Hat führt die Schwachstelle unter anderem im Zusammenhang mit EDK2/OVMF, der Firmware für virtuelle Maschinen, und prüft nach eigener Darstellung noch, welche Produkte betroffen sind.
Gibt es schon ein Update?
Im EDK-II-Quellcode ja. Der Fix kam über Pull Request #13302 und wurde am 15. Oktober 2026 übernommen. Er ergänzt die fehlende Längenprüfung und berechnet die Kopierposition korrekt; zu lange Meldungen werden nun abgeschnitten. Im Sicherheitshinweis selbst steht unter „Patched versions“ allerdings noch „Not patched currently“ – betroffen ist laut TianoCore der EDK-II-Stand vom 14. September 2026.
Für Admins entscheidend ist ein anderer Punkt: EDK II ist nur der Baukasten. Die Firmware auf einem konkreten Server, Mainboard oder in einer Virtualisierungsplattform liefert der jeweilige Hersteller. Erst wenn dieser den Fix übernimmt und ein BIOS-/UEFI-Update veröffentlicht, ist das einzelne Gerät geschützt. Erfahrungsgemäß dauert das bei Firmware deutlich länger als bei Betriebssystem-Updates. Gefunden haben die Lücke laut Advisory Alex Matrosov (Anthropic) und Dan Holmes-Mitra (Google), die auch den empfohlenen Fix geliefert haben.
Was Administratoren jetzt tun können
- Bestandsaufnahme: Welche Server, Clients und VMs starten tatsächlich per PXE? Nur diese sind über diesen Weg angreifbar.
- PXE abschalten, wo es nicht gebraucht wird: In vielen Firmware-Menüs lässt sich der Netzwerkstart pro Netzwerkkarte deaktivieren oder in der Bootreihenfolge nach hinten setzen.
- Bereitstellungsnetz abschotten: PXE-Installationen gehören in ein eigenes, streng kontrolliertes Netzsegment, in dem fremde Geräte keine Pakete einschleusen können.
- Hersteller-Hinweise verfolgen: Firmware-Updates der Server- und Mainboard-Hersteller sowie der Hypervisor-Anbieter (etwa OVMF-Pakete unter Linux) einspielen, sobald sie den Fix enthalten.
Einen eigenen Warnhinweis von BSI oder CISA zu CVE-2026-97631 haben wir bis zum Redaktionsschluss nicht gefunden; maßgeblich ist derzeit der Sicherheitshinweis von TianoCore.
Wie stark KI-gestützte Sicherheitsforschung gerade das Tempo bei solchen Funden erhöht, zeigt auch Anthropics aktueller Bericht über automatisch gebaute Exploit-Ketten für Chrome, Safari und Linux. Weitere kritische Lücken in Unternehmensinfrastruktur hatten wir zuletzt bei Citrix NetScaler und Atlassian Data Center beschrieben.
Häufige Fragen
Ist mein Laptop oder Heim-PC betroffen?
Über diesen Angriffsweg nur, wenn er per PXE über das Netzwerk startet. Das ist bei privaten Geräten praktisch nie der Fall – sie booten von der internen SSD.
Schützt Secure Boot vor dem Angriff?
Nein. Der Schadcode läuft in der DXE-Phase, bevor Secure Boot das Betriebssystem prüft. Genau das macht die Lücke so ernst.
Woher weiß ich, ob meine Firmware den Fix enthält?
Das kann nur der Hersteller des Servers, Mainboards oder der Virtualisierungslösung sagen. Achten Sie auf Firmware-Hinweise, die CVE-2026-97631 ausdrücklich nennen.
Wird die Lücke schon ausgenutzt?
Weder TianoCore noch Red Hat berichten bislang von Angriffen in freier Wildbahn.
