Firmware ist die Patch-Lücke, für die niemand zuständig ist – der neue UEFI-Fehler belegt es

Das EDR ist hervorragend, der Hypervisor aktuell, die Container-Images wurden gestern Nacht neu gebaut. Wer aber patcht den Code, der läuft, bevor all das überhaupt existiert?

Das ist die unbequeme Frage hinter CVE-2026-97631, einer kritischen Schwachstelle in TianoCore EDK II, der quelloffenen Referenzcodebasis, die die meisten UEFI-Firmware-Hersteller verwenden. Laut Zusammenfassungen von Ars Technicas Berichterstattung steckt sie in einer ICMP-Komponente im Netzwerk-Boot-Pfad und wird mit 9,5 von 10 Punkten bewertet. Sie erlaubt es einem Angreifer, während des Bootvorgangs Code auszuführen, noch bevor Schutzmechanismen wie Secure Boot und das TPM eine Vertrauenskette aufbauen können.

Einige Details sind wichtig. Die Payloads bleiben Berichten zufolge nicht von selbst bestehen, können aber anderen Code installieren, der bei jedem späteren Start läuft. Außerdem wurde die Schwachstelle laut einer Zusammenfassung von FourWeekMBA zu Ars öffentlich, bevor eine für Januar geplante Offenlegung stattfand. Und Jesse Michael von Eclypsium sagte gegenüber Ars, die Lösung bestehe darin, ein BIOS-/UEFI-Update einzuspielen.

„Die meisten Server der Erde“ ist eine Schlagzeile, keine Messung

Zunächst etwas Zurückhaltung. Die Schlagzeile besagt, die Schwachstelle bedrohe die meisten Server auf dem Planeten. Wie Tech Insider anmerkt, heißt es in der Berichterstattung, der Referenzcode werde von den meisten Serverherstellern weltweit genutzt, doch eine Zahl betroffener Systeme oder ein Prozentsatz wird nicht genannt. Gemeinsamer Code bedeutet nicht gleiche Gefährdung. Builds und Konfigurationen der Hersteller dürften sich unterscheiden, und ob ein bestimmtes System über diesen Netzwerk-Boot-Pfad erreichbar ist, hängt wahrscheinlich von der Einrichtung ab.

Wir meinen, diese Differenzierung gilt in beide Richtungen. Sie bedeutet, dass man heute Nacht nicht in Panik die gesamte Flotte neu starten sollte. Sie bedeutet aber auch, dass sich die eigene Gefährdung nicht aus einer Schlagzeile ableiten lässt – und wir vermuten, dass viele Organisationen sie auch anhand ihrer eigenen Unterlagen nicht beantworten können. Das ist die eigentliche Geschichte.

Der Fehler ist neu, die kaputte Lieferkette alt

Ein Blick darauf, wie ein Firmware-Fix reist. In Ars' Berichterstattung von 2024 über eine frühere Welle von UEFI-Fehlern war die Kette klar beschrieben: Firmware-Hersteller liefern Updates an ihre Kunden, und diese stellen die Patches ihren eigenen Kunden bereit, in der Regel den Endnutzern. Jede Station ist ein eigenes Unternehmen, und unserer Ansicht nach ist niemand für den gesamten Weg verantwortlich.

Zum Vergleich ein Fehler in einer Bibliothek. Als zuletzt eine Brotli-Schwachstelle bekannt wurde, veröffentlichten Google und Node.js am 21. Oktober Fixes, und Microsoft folgte über das Wochenende mit einem Notfall-Update für.NET, wie TechRadar berichtet. Selbst das war chaotisch: Mitgelieferte Kopien führen dazu, dass ein Update allein der Google-Bibliothek nicht jede Anwendung schützt. Der Fix läuft aber immerhin über Kanäle, die die meisten Teams ohnehin beherrschen, etwa Paket-Updates und Neu-Deployments. Für Firmware gibt es keine solche Routine. Man muss herausfinden, welches Hersteller-Image im Einsatz ist, warten, bis der OEM es neu paketiert, ein Wartungsfenster planen und Maschinen flashen, die niemand gern neu startet.

Hinzu kommt die Ebene, auf der Verteidiger ein Problem normalerweise bemerken würden. Pre-Boot-Code läuft unterhalb des Betriebssystems, sodass die Werkzeuge, auf die sich die meisten Teams stützen, dort womöglich kaum Einblick haben. Auch die vergangenen Monate waren für Firmware schlecht. Im September berichtete Cybernews von einer Umgehung von Secure Boot über die UEFI Shell, die AMI, Gigabyte, Insyde und Cisco bestätigten; wahrscheinlich sind noch viele weitere Hersteller betroffen. Zwei Vorfälle in zwei Monaten ergeben für sich genommen keinen Trend, deuten aber auf eine Schwachstelle im System hin.

Firmware als Produkt mit Verantwortlichem behandeln

Unser Urteil ist einfach: Wenn Firmware in Ihrem Team niemandem gehört, haben Sie sich bereits dafür entschieden, sie spät zu patchen. Die Lösung ist vor allem eine Frage des Prozesses, nicht der Werkzeuge.

• Inventarisieren. Wissen, welche Firmware-Version und welcher Hersteller-Build auf jedem Server läuft. Ohne das dauert die Frage „Sind wir betroffen?“ Tage statt Minuten.
• Verantwortlichen benennen. Jemand sollte Herstellerhinweise verfolgen und befugt sein, Wartungsfenster anzusetzen – so wie ein Team seinen Patch-Rhythmus fürs Betriebssystem verantwortet.
• Erreichbare Angriffsfläche verkleinern. Wird Netzwerk-Boot auf einer Maschine nicht benötigt, kann das Abschalten eine günstige Gegenmaßnahme sein. Wir können nicht versprechen, dass sie jede Konfiguration abdeckt; prüfen Sie daher die Angaben Ihres Herstellers.
• Das Flashen üben. Ein BIOS-Update, das nie auf der eigenen Hardware erprobt wurde, ist im Ernstfall ein Glücksspiel.

Auch die Hersteller haben Hausaufgaben. Eine branchenweit geteilte Referenzcodebasis sollte mit einem geteilten, verlässlichen Weg einhergehen, Fixes zu den Kunden zu bringen. Solange es den nicht gibt, liegt die Last bei den Administratoren – das ist unfair, aber Realität.

An diese CVE wird man sich nicht wegen ihrer Bewertung erinnern. Die entscheidende Frage lautet, wie lange Ihre Organisation brauchen würde, um zu wissen, welche ihrer Maschinen gefährdet sind. Lautet die ehrliche Antwort „Das müssten wir erst herausfinden“, dann ist Firmware Ihre Patch-Lücke, und niemand sonst wird sie schließen.