Die kritische buffer-overflow-Schwachstelle CVE-2026-97631 im PXE-Treiber von EDK II – dem Open-Source-Code, auf dem die UEFI-Firmware der meisten Server- und Client-Plattformen basiert – ermöglicht einem nicht authentifizierten Angreifer, beliebigen Code auszuführen, noch bevor das Betriebssystem geladen wird und bevor Secure Boot greift. Die Schwachstelle betrifft Systeme, die PXE-Netzwerkstart nutzen, und wurde mit 9.5 Punkten nach CVSS v4 (Critical) bewertet. Das Patch wurde in den Quellcode von EDK II eingepflegt, ist jedoch in noch keinem stabilen Release enthalten. Betreibern von Serverinfrastrukturen mit PXE-Start wird empfohlen, den Netzwerkstart bis zum Erscheinen von Firmware-Updates zu deaktivieren.
Technische Details der Schwachstelle
Die Schwachstelle wird als Schreibvorgang außerhalb des zugewiesenen Puffers klassifiziert (CWE-787, out-of-bounds write) in der Komponente NetworkPkg/UefiPxeBcDxe – dem PXE-Treiber von EDK II. PXE (Preboot Execution Environment) ist ein Mechanismus zum Starten von Maschinen über das Netzwerk, der in Rechenzentren weit verbreitet für Bereitstellung und Wiederherstellung von Servern eingesetzt wird.
Während des PXE-Starts verarbeitet der Treiber eingehende ICMP-Fehlermeldungen, indem er deren Inhalt in einen festen Speicherbereich mit einer Größe von 504 Byte kopiert. Die Grenzprüfungen für diesen Kopiervorgang sind sowohl für IPv4 als auch für IPv6 fehlerhaft implementiert. Das Senden eines speziell präparierten ICMP-Pakets, das größer als 504 Byte ist, führt dazu, dass angrenzende Speicherbereiche mit von dem Angreifer kontrollierten Daten überschrieben werden.
Für die Ausnutzung sind weder ein Passwort noch ein vorheriger Zugriff auf das System erforderlich – es genügt, zum Zeitpunkt des PXE-Starts ein Netzwerkpaket an die Adresse der Maschine senden zu können. Dabei klassifizieren laut CVE-Eintrag Red Hat und SUSE den Angriffsvektor als aus einem angrenzenden Netzwerksegment erreichbar und nicht aus dem offenen Internet.
Das garantierte Ergebnis einer Ausnutzung ist ein fehlgeschlagener Startvorgang (denial of service). Die Ausführung beliebigen Codes ist deutlich schwieriger: Sie erfordert genaue Kenntnisse über den konkreten Firmware-Build des Zielsystems und die Entwicklung eines darauf zugeschnittenen Exploits. Ein universeller Exploit für breit angelegte Angriffe ist gerade wegen dieser Abhängigkeit von der Konfiguration wenig wahrscheinlich.
Bemerkenswert ist die Abweichung in der Bewertung der Schwere durch verschiedene Quellen: TianoCore vergibt 9.5 nach CVSS v4, während SUSE die Schwachstelle mit 8.8 nach CVSS v3 (Important) bewertet. Das ist kein Widerspruch – der Unterschied ergibt sich aus den unterschiedlichen CVSS-Versionen; SUSE zeigt zusätzlich die CNA-Bewertung von 9.5 nach CVSS v4 an.
Umfang der betroffenen Systeme
Der verwundbare Code ist seit dem Commit vom November 2010 in EDK II vorhanden – die Schwachstelle existiert also seit rund 16 Jahren. Betroffen sind alle Versionen von EDK II bis einschließlich edk2-stable202608 (vom 21. August 2026).
EDK II ist eine Referenz-Codebasis, die von den größten UEFI-Firmware-Anbietern (AMI, Insyde, Phoenix) sowie von Microsoft im Project Mu verwendet wird. Die weite Verbreitung von EDK II im Ökosystem bedeutet jedoch nicht, dass alle Server verwundbar sind. Die praktische Betroffenheit ergibt sich aus dem gleichzeitigen Vorliegen von drei Bedingungen:
- Der PXE-Treiber von EDK II ist in der Firmware des Systems vorhanden;
- das System führt zum Zeitpunkt des Angriffs tatsächlich einen Netzwerkstart durch;
- der Angreifer kann zu diesem Zeitpunkt ICMP-Traffic an die Adresse der Maschine senden.
Heim- und Bürorechner, die von einem lokalen Datenträger starten, sind nicht betroffen. Die Haupt-Risikogruppe sind Server und Rechenzentrumsgeräte, die PXE für die Bereitstellung nutzen.
Unter den Linux-Distributionen: Red Hat führt die edk2-Pakete in RHEL 8, 9 und 10 als betroffen und noch nicht behoben; Debian verzeichnet die Schwachstelle in den Paketen bookworm, trixie, forky und sid. Zuvor haben wir bereits über Schwachstellen im Red-Hat-Ökosystem berichtet, und dieser Fall unterstreicht erneut das Ausmaß der Abhängigkeit von Enterprise-Linux-Distributionen von gemeinsamen Komponenten.
Laut Ars Technica teilte Intel mit, dass keines der kommerziellen, noch unterstützten Produkte betroffen sei, obwohl OEM-Hersteller die verwundbare Komponente selbst integrieren können. Arm gab an, dass die Schwachstelle für ihr Produktportfolio nicht relevant ist. Der Status der Produkte von AMD, Phoenix Technologies, AMI, Microsoft und Amazon ist zum Zeitpunkt der Veröffentlichung weiterhin unbekannt.
Status der Behebung und Offenlegungshistorie
Die Behebung wurde am 15. Oktober 2026 in den Hauptzweig von EDK II integriert. Das Patch schreibt den Kopiervorgang so um, dass Pakete, die 504 Byte überschreiten, abgeschnitten und nicht mehr außerhalb des Puffers geschrieben werden. Allerdings enthält noch kein stabiler Release von EDK II dieses Patch – die letzte Version edk2-stable202608 datiert vom 21. August, und im Sicherheitshinweis von TianoCore ist eine Version mit Behebung weiterhin als nicht vorhanden aufgeführt. Nach Angaben von Ars Technica hat Microsoft Project Mu das Patch bereits am 26. Oktober in seine Release-Zweige integriert.
Die Schwachstelle wurde von Alex Matrosov (Anthropic) und Dan Holmes-Mitra (Google) entdeckt. Eine koordinierte Offenlegung war für Januar 2027 geplant, doch am 28. September hat ein Pull Request eines AMI-Ingenieurs die Schwachstelle öffentlich mit Angabe der CVE-Nummer beschrieben und die Behebung enthalten. Daraufhin veröffentlichte TianoCore den Sicherheitshinweis am 22. Oktober – einige Wochen früher als geplant. Die öffentliche Verfügbarkeit des Patches bedeutet, dass qualifizierte Angreifer ihn analysieren können, um Exploits zu entwickeln.
Hinweise auf eine aktive Ausnutzung wurden bisher nicht gefunden. Die Schwachstelle wurde nicht in den CISA-KEV-Katalog aufgenommen.
Empfehlungen
Der zentrale Schwerpunkt sollte nicht auf dem Warten auf Paketupdates des Betriebssystems liegen, sondern auf der Beobachtung der Firmware-Updates des Hardwareherstellers, da der Firmware-Anbieter ein BIOS/UEFI-Update auf Basis des korrigierten EDK-II-Codes bereitstellen muss. Bis ein solches Update vorliegt:
- Deaktivieren Sie den PXE-Start auf allen Systemen, bei denen der Netzwerkstart für die Arbeitsabläufe nicht zwingend erforderlich ist;
- Überwachen Sie den Netzwerkverkehr in Segmenten, in denen PXE-Start genutzt wird, und achten Sie insbesondere auf ungewöhnliche ICMP-Pakete zum Zeitpunkt des Serverstarts;
- Nehmen Sie Kontakt mit dem Hersteller der Serverhardware oder des Mainboards auf, um den Betroffenheitsstatus und den Zeitplan für ein Firmware-Update zu klären;
- Beschränken Sie den Netzwerkzugriff auf Segmente mit PXE-Start, um die Möglichkeit der Zustellung beliebigen Traffics aus angrenzenden Netzen zu minimieren.
Ein wichtiger praktischer Punkt: Anders als bei Schwachstellen zur Umgehung von Secure Boot wie BootHole und BlackLotus wird CVE-2026-97631 durch ein normales Code-Update behoben und erfordert keinen Widerruf von Zertifikaten oder Schlüsseln, was den Patch-Prozess nach Veröffentlichung der Updates vereinfacht.
Organisationen, die Serverinfrastrukturen mit PXE-Start betreiben, sollten bereits jetzt eine Inventarisierung der Systeme mit aktivem Netzwerk-Bootloader durchführen, PXE dort deaktivieren, wo es nicht geschäftskritisch ist, und eine Anfrage an den Firmware-Anbieter dokumentieren – einen stabilen EDK-II-Release mit Behebung gibt es bislang nicht, und die Zeitpunkte der Integration in konkrete Produkte hängen jeweils vom einzelnen Hersteller ab.
