16 Jahre alte Firmware-Lücke: Warum Server beim Netzwerkstart angreifbar sind – und was Sie jetzt prüfen sollten

Die Schlagzeile klingt nach Weltuntergang: Eine kritische Firmware-Lücke gefährde „fast alle Server weltweit“, titelte derStandard. Ganz falsch ist das nicht. Die Schwachstelle steckt in einem Baustein, auf dem die Firmware der allermeisten Server und vieler PCs aufbaut, und sie war laut derStandard und t3n rund 16 Jahre lang unentdeckt. Ausnutzen lässt sie sich aber nur in einer bestimmten Situation: wenn ein Rechner über das Netzwerk startet.

Für die meisten mittelständischen Unternehmen heißt das: kein Grund zur Panik, aber ein guter Grund, heute nachzusehen. Denn ob ein Server über das Netzwerk startet, weiß im Betrieb oft niemand genau. Und die eigentliche Lösung, ein BIOS-Update, muss jeder Hersteller erst liefern. Wir fassen zusammen, was gesichert ist, was offen ist und was Sie bis dahin tun können.

Was ist bekannt?

Bevor Windows oder Linux überhaupt starten, läuft auf jedem modernen Rechner die UEFI-Firmware, der Nachfolger des klassischen BIOS. Sie prüft die Hardware und lädt das Betriebssystem. Ein Großteil dieser Firmware stammt nicht vom Server- oder PC-Hersteller selbst, sondern aus dem quelloffenen Projekt EDK II (TianoCore). Laut Dr. Web und The Next Web bauen die großen Firmware-Zulieferer AMI, Insyde und Phoenix darauf auf, ebenso Microsofts Firmware-Projekt Project Mu.

Die Lücke mit der Kennung CVE-2026-97631 steckt laut der Sicherheitswarnung von TianoCore vom 22. Oktober 2026 im Treiber für den PXE-Netzwerkstart. PXE erlaubt es, einen Rechner nicht von der eigenen Festplatte, sondern über das Netzwerk zu starten – etwa um Server oder Arbeitsplätze zentral zu installieren. Die Einzelheiten laut TianoCore:

• Der Fehler: Während des Netzwerkstarts nimmt der Treiber ICMP-Fehlermeldungen entgegen und kopiert sie in einen festen Speicherbereich von 504 Byte. Die Länge wird dabei nicht richtig begrenzt, längere Nachrichten schreiben über den Bereich hinaus. Betroffen sind IPv4 und IPv6.
• Die Folgen: Im harmlosesten Fall hängt der Startvorgang, der Server fährt nicht hoch. Kennt ein Angreifer den genauen Firmware-Stand des Zielgeräts, kann er eigenen Code mit höchsten Prozessorrechten ausführen – bevor das Betriebssystem lädt und bevor Secure Boot irgendetwas prüft.
• Die Bewertung: TianoCore stuft die Lücke als kritisch ein, mit 9,5 von 10 Punkten nach CVSS 4.0. Red Hat und SUSE bewerten sie laut The Next Web etwas niedriger, weil der Angreifer aus ihrer Sicht im angrenzenden Netz sitzen muss.
• Die Voraussetzung: Das Gerät muss gerade per PXE starten. Rechner, die von ihrer eigenen Festplatte oder SSD booten, sind laut Thomas-Krenn, Dr. Web und The Next Web nicht betroffen.

Gefunden haben die Lücke laut TianoCore Dan Holmes-Mitra (Google) und Alex Matrosov (Anthropic). Es ist nicht der erste Fehler an dieser Stelle: Bereits im Januar 2024 hatte Quarkslab unter dem Namen „PixieFail“ neun Schwachstellen im selben Netzwerkcode von EDK II beschrieben, worauf Dr. Web hinweist.

Warum die Korrektur zu früh öffentlich wurde

Die Entdecker wollten die Lücke nach Angaben von Ars Technica, wiedergegeben von t3n und The Next Web, eigentlich erst im Januar 2027 öffentlich machen – mit genug Vorlauf für die Hersteller. Daraus wurde nichts. Laut Dr. Web wurde die Korrektur samt Fehlerbeschreibung bereits am 28. September öffentlich im EDK-II-Projekt eingereicht; Ars Technica ordnet den Beitrag nach Angaben von The Next Web einem Mitarbeiter von AMI zu. Am 15. Oktober übernahm das Projekt die Korrektur, am 22. Oktober folgte die offizielle Warnung.

Das Problem daran: Wer eine Korrektur im Quelltext lesen kann, sieht auch, wo der Fehler sitzt. Angreifer haben also seit Wochen eine Anleitung, während die Hersteller ihre BIOS-Updates noch bauen. Die Warnung von TianoCore nennt bis heute keine korrigierte stabile Version; in den Entwicklungszweig ist die Korrektur eingeflossen, in fertiger Firmware steckt sie erst nach und nach. Microsoft hat laut The Next Web am 26. Oktober Project-Mu-Versionen mit der Korrektur veröffentlicht, Supermicro laut Thomas-Krenn Sicherheitsmeldungen mit neuen BIOS-Versionen für einzelne Mainboard-Serien. Intel kennt nach eigener Aussage keine unterstützten Produkte, die betroffen sind; AMI, Phoenix, AMD und Microsoft haben auf Anfrage von Ars Technica laut The Next Web nicht reagiert.

Wie groß ist die Gefahr wirklich?

Die gute Nachricht zuerst: Angriffe sind bisher nicht bekannt. Die US-Behörde CISA führte die Lücke laut The Next Web Ende Oktober nicht in ihrer Liste aktiv ausgenutzter Schwachstellen. Und ein Angriff ist aufwendig: Laut Jesse Michael vom Firmware-Sicherheitsspezialisten Eclypsium, zitiert von Dr. Web, muss jeder Exploit auf Modell, Firmware-Version und Konfiguration zugeschnitten werden. Thomas-Krenn weist ebenfalls darauf hin, dass ein Angreifer dafür Systemadressen kennen oder erraten muss.

Trotzdem ist die Einstufung als kritisch berechtigt, aus drei Gründen:

• Der Angriff findet unterhalb aller Schutzmaßnahmen statt. Virenschutz, EDR und Secure Boot setzen erst später ein. Wer sich in der Firmware einnistet, ist für diese Werkzeuge praktisch unsichtbar. HD Moore vom Sicherheitsunternehmen Dragos hält laut Dr. Web und The Next Web sogar an das TPM gebundene Festplattenverschlüsselung für angreifbar.
• Ein Paket genügt. Laut TianoCore reicht eine einzelne ICMP-Fehlermeldung an die Adresse des startenden Geräts, ohne Anmeldung. Wer bereits im Firmennetz ist – etwa über einen gekaperten Arbeitsplatzrechner –, kann so den nächsten Neustart eines Servers abpassen.
• Alte Geräte bleiben offen. HD Moore rechnet laut Dr. Web damit, dass die Lücke in nicht mehr gepflegten Altsystemen dauerhaft bestehen bleibt. Für Server, deren Hersteller kein BIOS-Update mehr liefert, gibt es keine Korrektur.

Ähnlich wie bei der Lazarus-Kampagne, die Windows-Schutzsoftware blind schaltete, gilt auch hier: Ein grünes Häkchen in der Sicherheitssoftware sagt nichts darüber aus, was unterhalb des Betriebssystems passiert.

Betrifft das Ihr Unternehmen?

In einem typischen mittelständischen Betrieb starten die Server von ihren eigenen Datenträgern. Dann ist die Lücke im Alltag nicht ausnutzbar. Nach unserer Erfahrung lohnt aber ein genauer Blick auf diese Stellen:

• Installation über das Netzwerk. Wer Server oder Arbeitsplätze zentral per Netzwerk installiert – etwa mit Windows-Bereitstellungsdiensten oder ähnlichen Werkzeugen –, nutzt PXE. Die Warnung von TianoCore betrifft den PXE-Treiber generell, nicht nur Server. Nach unserer Einschätzung gehören deshalb auch PCs dazu, die zur Neuinstallation über das Netzwerk starten.
• Netzwerkstart in der Bootreihenfolge. In vielen BIOS-Einstellungen steht der Netzwerkstart als Ausweichoption hinter der Festplatte. Findet der Rechner seinen Datenträger einmal nicht, versucht er es über das Netz. Ob das bei Ihnen so eingestellt ist, weiß oft niemand mehr.
• Gemietete Server. Hetzner hat für dedizierte Server und Cloud-Server mit UEFI einen eigenen Störungseintrag angelegt. Laut Hetzner ist ein laufendes System nicht unmittelbar gefährdet; das Risiko besteht bei dedizierten Servern während eines Neustarts und bei Cloud-Servern beim Start ins Rettungssystem. Der Anbieter empfiehlt, solche Startvorgänge bis zu einer Lösung möglichst zu vermeiden und eingehende ICMP-Pakete währenddessen per Firewall zu sperren.
• Ältere Server ohne Herstellerpflege. Läuft bei Ihnen ein Server, für den es seit Jahren kein BIOS-Update mehr gab, wird sich daran auch jetzt nichts ändern.

Für Einrichtungen, die unter NIS2 fallen, ist das Thema auch formal relevant: Laut Dr. Web verlangt § 30 BSIG Schwachstellenmanagement und eine sichere Lieferkette, und dazu gehört aktuelle Server-Firmware. Mehr zu den Pflichten in NIS2: Was Unternehmen jetzt wissen und tun müssen.

Was Sie jetzt konkret tun sollten

• Erfassen Sie, welche Geräte per Netzwerk starten. Das ist die erste Empfehlung von Dr. Web und t3n. Gehen Sie Server, Hypervisor-Hosts und Netzwerkgeräte durch und prüfen Sie im BIOS bzw. im Fernwartungsmodul (iDRAC, iLO, IPMI), ob PXE aktiviert ist und wo es in der Bootreihenfolge steht. Eine aktuelle Inventarliste mit Modell und BIOS-Stand spart dabei viel Zeit – siehe IT-Dokumentation: Warum sie oft fehlt und was das kostet.
• Schalten Sie den Netzwerkstart ab, wo Sie ihn nicht brauchen. Laut Dr. Web und t3n ist das bis zum Update die wirksamste Maßnahme. Bei den meisten Servern im Mittelstand fällt das gar nicht auf.
• Schotten Sie das Bootnetz ab, wo Sie PXE brauchen. Der Netzwerkstart gehört in ein eigenes Netzsegment, aus dem Arbeitsplatzrechner und Gästenetz keine Pakete senden können. Auch das empfehlen Dr. Web und t3n.
• Fragen Sie beim Hersteller nach dem BIOS-Update. Basiert die Firmware auf EDK II, und wann kommt die Korrektur? Bei Supermicro gibt es laut Thomas-Krenn bereits erste Versionen, für andere Hersteller lagen bei Redaktionsschluss noch keine belastbaren Angaben vor. Wer Server bei einem Hoster mietet, fragt dort nach dem Termin.
• Spielen Sie das Update ein, sobald es erscheint. Laut Jesse Michael (Eclypsium), zitiert von The Next Web und Dr. Web, ist diesmal kein Schlüsseltausch wie bei früheren Secure-Boot-Lücken nötig – ein normales Firmware-Update genügt. BIOS-Updates gehören in ein Wartungsfenster und sollten mit einem aktuellen Backup vorbereitet werden. Grundlagen dazu in Patch-Management: Der unterschätzte Schutz vor Cyberangriffen.
• Planen Sie Neustarts bewusst. Die gefährliche Phase ist der Startvorgang selbst. Starten Sie betroffene Server bis zum Update nicht unnötig neu, und wenn doch, dann kontrolliert und mit gesperrtem ICMP, wie Hetzner es für seine Kunden empfiehlt.
• Nehmen Sie Altgeräte aus dem Bootnetz. Server ohne Aussicht auf ein Update sollten laut Dr. Web aus dem Netzwerkstart herausgenommen werden, bevor es für ihr Modell einen Exploit gibt. Mittelfristig gehören sie ersetzt.

Unser Fazit

Nach PHP2Shell ist das innerhalb weniger Tage schon die zweite kritische Lücke, deren Korrektur öffentlich wurde, bevor die Hersteller fertig waren – siehe „PHP2Shell“: Warum Websites vorsorglich vom Netz gingen. Der Unterschied: Diesmal liegt der Fehler nicht in einer Anwendung, sondern in der Firmware, an die im Alltag kaum jemand denkt und die kein automatisches Update bekommt.

Akut ist die Lage für die meisten Unternehmen nicht. Aber sie zeigt, wie wertvoll es ist, zu wissen, welche Geräte man betreibt, wie sie eingestellt sind und ob der Hersteller sie noch pflegt. Wer das weiß, ist in einer Stunde fertig. Wer es nicht weiß, sucht tagelang. Firmware gehört ins Patch-Management – genauso wie Windows, Linux und die Firewall.

So können wir Ihnen helfen

BIOS-Updates sind keine Aufgabe, die man nebenbei erledigt: Sie brauchen ein Wartungsfenster, ein Backup und jemanden, der weiß, welche Geräte überhaupt dazugehören. Genau das gehört bei uns zur laufenden Betreuung – inklusive Lifecycle-Management, damit Server ersetzt werden, bevor der Hersteller sie aufgibt.

Quellen:
• TianoCore EDK II – „Pre-boot RCE in EDK II PXE driver“ (Sicherheitswarnung GHSA-99cj-7hg9-mp4m, CVE-2026-97631, 22.10.2026), zum Beitrag
• derStandard – „Kritische Firmware-Lücke gefährdet fast alle Server weltweit“ (Oktober 2026, Volltext nur mit Abo bzw. ohne Werbeblocker), zum Beitrag
• t3n – „UEFI-Lücke: Kritischer Bug versteckt sich seit 16 Jahren in vielen Servern“ (Jörn Brien, 28.10.2026), zum Beitrag
• Dr. Web – „Kritische Sicherheitslücke in UEFI-Firmware bedroht Server, die über das Netzwerk starten“ (Michael Dobler, 28.10.2026), zum Beitrag
• The Next Web – „Critical UEFI firmware flaw leaks early, leaving servers waiting for a fix“ (Ana Maria Constantin, 28.10.2026), zum Beitrag
• Thomas-Krenn – „Kritische PXE Boot Sicherheitslücke in EDK2“ (Wiki, laufend aktualisiert, Stand 30.10.2026), zum Beitrag
• Hetzner – „CVE-2026-97631 – critical security vulnerability in the EDK II UEFI firmware component“ (Statusmeldung, seit 28.10.2026), zum Beitrag
Die genannten Quellen wurden ausgewertet und für Unternehmen in Deutschland eingeordnet.