Eine einzige ICMP-Fehlermeldung genügt, um auf einem startenden Server Schadcode noch vor dem Betriebssystem auszuführen. Die kritische Sicherheitslücke CVE-2026-97631 steckt in EDK II, der quelloffenen UEFI-Referenzimplementierung, auf der die Firmware-Zulieferer AMI, Insyde und Phoenix aufbauen. Weil die Korrektur Monate vor dem vereinbarten Termin öffentlich wurde, können Angreifer den Fehler längst nachvollziehen.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügen504 Byte fasst der Puffer, in den der Netzwerktreiber eingehende ICMP-Fehlermeldungen kopiert. Längere Nachrichten schreibt der Code über den Puffer hinaus in angrenzenden Speicher.[1] Die Entdecker Alex Matrosov von Anthropic und Dan Holmes-Mitra von Google wollten den Fund bis Januar unter Verschluss halten.
Das Wichtigste in Kürze
- CVE-2026-97631 erreicht 9,5 von 10 Punkten (CVSS 4.0), betroffen ist der PXE-Treiber von EDK II für IPv4 und IPv6.
- Angreifer brauchen Zugang zu dem Netz, über das ein Rechner per PXE startet.
- Die Korrektur steht seit dem 15. Oktober im Hauptzweig von EDK II, Geräte erhalten den Schutz nur per Firmware-Update.
- Intel zufolge sind seine gepflegten Produkte nicht betroffen, AMD, AMI, Phoenix und Microsoft schwiegen auf Anfrage von Ars Technica.
Wie gelangt der Schadcode vor das Betriebssystem?
Beim Netzwerkstart per PXE lädt ein Rechner sein Betriebssystem von einem Bootserver im lokalen Netz. Verbreitet ist das Verfahren in großen Rechenzentren, die Hunderte Server identisch einrichten.[3] Während dieser Phase nimmt der Treiber in EDK II ICMP-Fehlermeldungen entgegen. Die Kopierschleife berechnet die Puffergrenze falsch; beim Empfang prüft keine Stelle die Länge der Nachricht.[1]
Im harmlosesten Fall bleibt der Start hängen. Kennt der Angreifer den genauen Firmware-Stand, schleust er mit demselben Paket eigenen Code ein, der mit den höchsten Rechten des Prozessors läuft, bevor Secure Boot das Betriebssystem prüft.[1] HD Moore, Forschungschef beim Sicherheitsanbieter Dragos, hält damit auch Festplattenverschlüsselung für angreifbar, die ihren Schlüssel aus dem TPM-Chip bezieht.[2]
Warum lag die Korrektur vor der Warnung im Netz?
Am 28. September reichte ein Entwickler die Korrektur samt Fehlerbeschreibung öffentlich im EDK-II-Projekt ein, Ars Technica ordnet den Beitrag AMI zu.[2] Am 15. Oktober übernahm das Projekt die Korrektur, am 22. Oktober folgte die Sicherheitswarnung.[1] Angreifern genügt der Vergleich von altem und neuem Code, um einen Angriff zu entwickeln. Bei der PHP-Sicherheitslücke PHP2Shell meldeten Hoster vor einer Woche Angriffe, noch bevor das Update erschien.
Im Januar 2024 beschrieb Quarkslab als PixieFail neun Schwachstellen im selben Netzwerkcode von EDK II.[3] Bei anschließenden Fuzzing-Tests mit Zufallseingaben blieb der neue Fehler nach Einschätzung von Ars Technica unentdeckt.[2] Wie angreifbar Secure Boot auf Chip-Ebene ist, zeigte zuletzt ein Laserangriff auf den Mikrocontroller RP2350.
Wie wurde der Fehler öffentlich?
Die Sicherheitslücke in Zahlen
Den Patch kennen Angreifer seit Wochen, das BIOS-Update muss jeder Serverhersteller erst selbst erstellen.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Unternehmen im DACH-Raum jetzt tun?
Der Fehler betrifft keine Rechner, die nur vom eigenen Laufwerk starten. Zudem müssen Angreifer jeden Exploit an Modell, Firmware-Version und Konfiguration anpassen, betont Jesse Michael vom Firmware-Sicherheitsanbieter Eclypsium.[2] Für NIS2-Einrichtungen bleibt die Lücke trotzdem Pflichtthema: § 30 BSIG verlangt ein Schwachstellenmanagement und eine sichere Lieferkette, also auch aktuelle Server-Firmware.[4] Vier Schritte helfen:
- Bestand prüfen: Erfassen Sie, welche Server und Netzwerkgeräte per PXE starten, und fragen Sie die Hersteller gerne, ob ihre Firmware auf EDK II beruht.
- Netzwerkstart abschalten: Wo kein Gerät PXE braucht, deaktivieren Sie die Funktion bis zum Update.
- Bootnetz abschotten: PXE gehört in ein eigenes Netzsegment, in das Arbeitsplatzrechner und Geräte im Gästenetz keine Pakete schicken können.
- Updates einplanen: Anders als bei früheren Secure-Boot-Umgehungen genügt ein Firmware-Update ohne Schlüsseltausch. Mieter dedizierter Server fragen beim Hoster nach dem Termin.
Moore rechnet damit, dass der Fehler in ungepflegten Altsystemen dauerhaft bleibt.[2] Solche Server gehören aus dem Bootnetz, bevor ein Exploit für ihr Modell existiert.
Quellen
4 Quellen anzeigenQuellen ausblenden
- TianoCore EDK IIPre-boot RCE in EDK II PXE driver, Sicherheitswarnung GHSA-99cj-7hg9-mp4m
- Ars TechnicaCode-execution flaw in UEFI firmware affects most servers on planet Earth, Dan Goodin
- QuarkslabPixieFail: Nine vulnerabilities in Tianocore’s EDK II IPv6 network stack, Francisco Falcon und Iván Arce
- Bundesministerium der Justiz§ 30 BSIG, Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen
Mehr Newshunger?
- PHP2Shell in PAN-OS: Die letzten Hotfixes von Palo Alto folgen am 30. Oktober
- Nginx: Drei kritische Sicherheitslücken im Webserver fast jeder dritten Website
- Kampagne gegen Fortinet und Palo Alto: Angreifer erbeuteten mehr als 70.000 Zugangsdaten
- Arista: Angreifer nutzen die dritte kritische VeloCloud-Sicherheitslücke seit Juli
- GitLab: Kritische Sicherheitslücke trifft alle Versionen seit 2014
- Lücke in Broadcoms WLAN-Software: Viele Router lassen sich per Funk übernehmen
