Firmware gilt oft als Code, der einmal geschrieben und jahrelang nicht angefasst wird. Die Schwachstelle CVE-2026-97631 sitzt in der EDK2-Codebasis von TianoCore, aus der praktisch alle großen UEFI-Anbieter ihre Firmware ableiten. Sie lässt sich ausnutzen, bevor Secure Boot, TPM oder das Betriebssystem greifen. Dan Goodin beschreibt bei Ars Technica eine Lücke mit Schweregrad 9,5 von 10 und einen Offenlegungsprozess, der schiefging, bevor die Hersteller koordiniert reagieren konnten. Das Muster ist bekannt. Die Tragweite diesmal nicht.
Der Bootvorgang läuft in Stufen. Zuerst initialisiert die UEFI-Firmware den Speicher, spricht Geräte an und startet die nächste Instanz. Erst danach kommen Bootloader, Betriebssystem und Anwendungen. Wer diese erste Stufe kontrolliert, kontrolliert alles, was danach kommt. Genau darum geht es bei dieser Schwachstelle.
Ein sechzehn Jahre alter Pufferüberlauf im PXE-Treiber von EDK2
Die Lücke steckt in einem Treiber, der bei Servern eine Routineaufgabe erledigt: dem PXE Base Code Driver im EDK2-Paket NetworkPkg/UefiPxeBcDxe. PXE (Preboot Execution Environment) erlaubt einer Maschine, ihr Betriebssystem oder ein Installationsimage nicht von der eigenen Platte, sondern aus dem lokalen Netz zu laden. Damit dieser Vorgang robust läuft, hält der Treiber eine Empfangsanfrage für ICMP-Fehlermeldungen offen – kurze Statusnachrichten, mit denen Router und Gegenstellen mitteilen, dass ein Paket nicht angekommen ist. Jede eingehende Meldung kopiert der Code in ein Feld namens Mode.IcmpError, das fest 504 Byte groß ist.
Genau dort liegt der Fehler, und er ist sechzehn Jahre alt. Die Begrenzung der Kopierschleife ist in beiden Handlern falsch umgesetzt: in PxeBcIcmpErrorDpcHandle für IPv4 und in PxeBcIcmp6ErrorDpcHandle für IPv6. Ist eine Nachricht länger als 504 Byte, schreibt der Code trotzdem weiter. Zusätzlich verschiebt er den Zielzeiger um die kumulierte statt um die einzelne Fragmentlänge. Eine überlange Nachricht schreibt so Bytes hinter das Feld, die der Angreifer kontrolliert. Auf dem Empfangspfad davor prüft niemand die Länge. Ein einziges Unicast-Paket, zur richtigen Zeit während des Netzwerk-Boots gesendet, genügt für den ersten Schritt.
Wie die Lücke die Vertrauenskette von Secure Boot umgeht
Das klingt nach einem gewöhnlichen Overflow, trifft aber eine frühe Boot-Phase. Der beschädigte Speicher gehört zum UEFI-Modul, das direkt auf der CPU läuft – im Ring 0, der privilegiertesten Ebene eines Prozessors. Zu diesem Zeitpunkt ist das Betriebssystem noch nicht geladen, Secure Boot hat seine Prüfkette noch nicht abgeschlossen, und das TPM hat noch keine Messwerte versiegelt. Die Verteidigung kommt also später als der Angriff. Das ist der Kern des Problems.
Der Sicherheitsforscher HD Moore, Erfinder von Metasploit und heute Research-Chef bei Dragos, sagt gegenüber Ars Technica, ein Angreifer könne den Programmfluss an einer Stelle kapern, an der der Bootvorgang noch Zugriff auf sensible Komponenten wie das TPM habe. Damit lässt sich Festplattenverschlüsselung brechen, wenn jemand kurzfristig Netzwerkzugang hat. Im Diebstahlsfall wäre es laut Moore noch einfacher. Praktisch heißt das: Die Bescheinigung, die ein Server einem entfernten Prüfsystem über seine Vertrauenswürdigkeit vorlegt, kann gefälscht werden, weil der Code, der sie erzeugt, bereits manipuliert ist. Die Forscher nennen das ein „counterfeit event“.
Betroffen sind Server mit Netzwerk-Boot – die Hersteller bleiben vage
Der Angriffsvektor ist eng umrissen. Wer seinen Rechner ausschließlich von der lokalen Festplatte startet, ist nicht betroffen; private Haushalte und kleine Büros fallen damit praktisch aus dem Kreis heraus. Es geht um Rechenzentren, Storage-Systeme und Cloud-Umgebungen, in denen Maschinen provisioniert werden, indem sie ihr Image per PXE aus dem Netz ziehen. Dort ist PXE häufig standardmäßig aktiv. Der Angreifer muss sich nicht am Zielgerät befinden – ein Paket aus beliebiger Netzwerkentfernung reicht, solange es während des Bootvorgangs ankommt.
Eine klare Liste betroffener Produkte gibt es nicht. Intel teilte mit, keines seiner derzeit unterstützten kommerziellen Produkte sei bekanntermaßen betroffen. Die fragliche EDK2-Funktionalität stecke nicht im Referenzcode, könne aber von Mainboard- und Systemherstellern integriert worden sein. Arm erklärte, die Lücke sei auf das eigene Portfolio nicht direkt anwendbar. AMD, Phoenix Technologies, AMI, Microsoft und Amazon beantworteten entsprechende Fragen nicht; das TianoCore-Projekt blieb eine Antwort schuldig. Microsoft verwendet mit Project Mu einen gehärteten EDK2-Ableger, der den verwundbaren Code enthielt.
Ein gebrochenes Embargo und die Folgen für den Patch-Zeitplan
Entdeckt wurde die Schwachstelle von Alex Matrosov, der inzwischen bei Anthropic arbeitet, und Dan Holmes von Google. Die beiden hatten eine koordinierte Veröffentlichung für Januar vorgesehen – ein Verfahren, bei dem Hersteller Zeit bekommen, Patches zu bauen, bevor Details öffentlich werden. Dieser Plan hielt nicht. AMI veröffentlichte bereits im Vormonat einen Pull Request, der die Lücke beschrieb und einen Code-Fix enthielt. Nachdem dieser Beitrag den Entdeckern aufgefallen war, veröffentlichte das TianoCore-Projekt in der vergangenen Woche eine öffentliche Warnung.
Damit liegt funktionsfähiger Patch-Code offen, und erfahrene Angreifer können daraus einen Exploit bauen. Das Problem ist weniger die Lücke allein als das Timing ihrer Veröffentlichung. Wer eine Serverflotte betreut, muss nun schneller reagieren, als der ursprüngliche Fahrplan vorsah. Nur sechs Tage zuvor war bereits eine kritische Code-Ausführungslücke in der Programmiersprache PHP vorzeitig bekannt geworden. Das wiederholt sich.
Was Betreiber jetzt tun können
Die erste Frage lautet nicht, ob ein Patch existiert, sondern ob das eigene Gerät überhaupt betroffen ist. Ein Blick ins Firmware-Inventar hilft: Läuft dort EDK2-basierte Firmware, ist Netzwerk-Boot aktiviert, und wird es tatsächlich genutzt? Wer PXE nicht braucht, kann es abschalten und damit den Angriffsvektor schließen, ohne auf ein Herstellerupdate zu warten. Wo Netzwerk-Boot gebraucht wird, hilft eine Segmentierung, die ICMP-Fehlermeldungen aus fremden Netzen gar nicht erst an die Boot-Schnittstelle lässt.
Der Firmware-Sicherheitsforscher Jesse Michael von Eclypsium weist auf einen Unterschied zu früheren Fällen hin. Der Angreifer muss spezifische Adressen im Zielsystem erraten; ein einziger Exploit funktioniert deshalb nicht gegen beliebige Geräte, sondern muss pro Modell, Version und Konfiguration angepasst werden. Dafür lässt sich diese Lücke mit einer einfachen Code-Korrektur beheben, die ein BIOS- oder UEFI-Update erfordert. Anders als bei BootHole oder BlackLotus sind keine Widerrufslisten, keine Schlüsselverwaltung und keine Anpassung von Installationsmedien nötig.
Ein Firmware-Update muss durch Hersteller, OEMs und Betreiber hindurch, und das dauert Monate. Wer eine Flotte betreibt, sollte beim Hersteller konkret nachfragen, statt sich auf allgemeine Statements zu verlassen, die TPM und Secure Boot als Schutz empfehlen, obwohl beide in diesem Szenario nichts bringen. Sinnvoll ist zusätzlich, Boot-Logs und Netzwerkverkehr auf ICMP-Fehlerpakete zu prüfen, die während Provisionierungsphasen aus unerwarteten Quellen kommen.
Warum Firmware-Lücken nicht verschwinden
CVE-2026-97631 steht in einer Reihe ähnlicher Firmware-Fehler. PixieFail war eine PXE-Schwachstelle in EDK2, LogoFail entstand aus Bilddaten in der Firmware nahezu jedes Herstellers, PKFail aus jahrelang öffentlich bekannten Testschlüsseln in hunderten Gerätemodellen. BootHole und BlackLotus zeigten, dass sich Bootkits wirtschaftlich lohnen, weil sie vor allen Schutzmechanismen greifen. Nach PixieFail hatten Forscher mehrere Fuzzing-Kampagnen gestartet, um weitere kritische Fehler in der Codebasis zu finden. Diese Lücke haben sie nicht gefunden.
Moore rechnet damit, dass der Fehler auf Systemen ohne Support dauerhaft überlebt – ein „forever“ Bug, wie er es nennt. Das beschreibt die Update-Realität im Firmware-Bereich. Die Konsequenz ist unspektakulär: Inventar prüfen, Firmware-Versionen dokumentieren, nicht benötigten Netzwerk-Boot abschalten und Herstellerangaben mit gesundem Misstrauen lesen. Firmware ist Software. Sie braucht Patches, Inventar und Prüfung – wie der Rest des Stacks.
Quelle: arstechnica.com
