Sicherheitsteams haben diese Woche eine weitere ungeplante Offenlegung bekommen – und diesmal liegt sie unter dem Betriebssystem statt in ihm.
CVE-2026-97631 ist ein Pufferüberlauf in der TianoCore-EDK-II-Codebasis, der Open-Source-Referenzimplementierung, aus der AMI, Insyde, Phoenix und Microsofts gehärteter Project-Mu-Fork ihre UEFI-Firmware bauen. Betroffen ist der PXE-Base-Code-Treiber (NetworkPkg/UefiPxeBcDxe), der einen Rechner von Code starten lässt, den er über ein lokales Netzwerk bezieht. Während dieses Bootvorgangs hält der Treiber eine Empfangsanforderung für ICMP-Fehlermeldungen offen und kopiert jede davon in ein festes 504-Byte-Feld. Die Grenzprüfung ist in den IPv4- und IPv6-Handlern falsch, sodass eine überlange Nachricht angreiferkontrollierte Bytes über das Feld hinaus schreibt und das auf der CPU laufende Modul beschädigt.
Das Ergebnis ist Codeausführung in Ring 0 innerhalb der Firmware-Umgebung – bevor Secure Boot oder das TPM eine Vertrauenskette aufbauen können. So gelieferte Payloads sind für sich genommen nicht persistent, laufen aber in genau dem Moment, in dem ein Angreifer etwas Dauerhaftes platzieren kann.
Die Voraussetzungen sind wichtig. Ein Angreifer braucht eine gewisse Kontrolle über ein lokales Netz, muss das Paket während der PXE-Bootsequenz senden und die Adressen auf den Firmware-Build des Ziels abstimmen. Wie Jesse Michael von Eclypsium Ars Technica sagte, ist das kein Exploit, den man auf jedes Ziel wirft: Modell, Version und Konfiguration verändern die Adressen. HD Moore, heute Forschungsleiter bei Dragos, erwartet einen Forever-Bug, der in Systemen ohne Support weiterlebt.
Die Offenlegung ist Teil der Geschichte. Alex Matrosov von Anthropic und Dan Holmes von Google fanden den Fehler, eine koordinierte Veröffentlichung war für Januar geplant. AMI veröffentlichte im vergangenen Monat einen Pull Request, der die Schwachstelle samt Fix beschrieb; TianoCore folgte letzte Woche mit einer öffentlichen Warnung. Mit offenem Patch-Code sind funktionierende Exploits nun eine Frage des Aufwands, nicht der Erkenntnis.
Die Herstellerantworten sind dünn. Intel erklärte, keines seiner kommerziell unterstützten Produkte sei bekanntermaßen betroffen, und die betroffene EDK2-Funktion sei nicht in seinem Referenzcode enthalten – ein OEM könne sie aber integrieren. Arm erklärte, der Fehler sei auf sein Portfolio nicht direkt anwendbar. AMD, Phoenix, AMI, Microsoft und Amazon hatten Ars zum Zeitpunkt der Veröffentlichung nicht geantwortet. Sowohl Intel als auch Arm veröffentlichen Code, der stark auf EDK2 zurückgreift, und TianoCore hat diese Abhängigkeit dokumentiert.
Der praktische Rat ist unspektakulär: beim Firmware-Hersteller ein Update anfordern und Netzwerkboot zumindest vorübergehend abschalten, wo es nicht gebraucht wird. Secure Boot und TPM helfen hier nicht, weil der Angriff vor ihrem Laden läuft. Jesse Michael nennt einen Trost: Diese Fehlerklasse wird mit einem gewöhnlichen BIOS-Update behoben, ohne die Schlüsselwiderrufe und neu erstellten Datenträger, die eine Secure-Boot-Umgehung erfordert.
Der Fehler reiht sich in ein volles Regal ein: PixieFail war eine ähnliche PXE-Schwachstelle in EDK2, und LogoFail, PKFail, BootHole und BlackLotus nutzten dasselbe Frühboot-Fenster. Fuzzing-Kampagnen nach PixieFail fanden diese Lücke nicht. Die Warnung kommt zudem sechs Tage, nachdem eine kritische Codeausführungslücke in PHP öffentlich wurde – ein eigener Beleg dafür, wie Firmware- und Bibliotheksoffenlegungen ihren Embargoes immer wieder entkommen.
