CVE-2026-97631: Kritische UEFI-Lücke beim PXE-Boot – Server und Proxmox prüfen

Stand: 30. Oktober 2026. Die Sicherheitsmeldung ist bestätigt; der Stand verfügbarer Firmware-Updates kann sich kurzfristig ändern.

Du schaltest deinen Server ein, das UEFI startet, und erst danach übernimmt Linux, Windows oder dein Hypervisor. Genau in dieser frühen Phase sitzt eine neue, kritische Sicherheitslücke. CVE-2026-97631 betrifft den Netzwerkstart über PXE in bestimmten UEFI-Firmware-Implementierungen. Ein speziell präpariertes Netzwerkpaket kann dabei Speicher beschädigen – unter bestimmten Bedingungen sogar Code ausführen, bevor das Betriebssystem und seine Sicherheitsmechanismen überhaupt laufen.

Das klingt nach einem Problem für jeden PC. Die entscheidende Einschränkung lautet jedoch: Der gefährliche Codepfad wird während eines PXE-Netzwerkstarts erreicht. Wer ausschließlich von einer lokalen SSD startet, ist nach den bisher veröffentlichten Informationen nicht über diesen Angriffsweg exponiert. Besonders aufmerksam sollten Administratoren von Provisioning-Netzen, Bare-Metal-Servern und virtuellen Maschinen mit Netzwerkboot sein.

In dieser Anleitung erkläre ich verständlich, was bestätigt ist, wer wirklich betroffen sein kann und wie du dein eigenes Setup prüfst, ohne voreilig Änderungen an produktiven Systemen vorzunehmen.

CVE-2026-97631: Was genau wurde entdeckt?

Das Open-Source-Projekt TianoCore hat am 22. Oktober 2026 eine kritische Schwachstelle in EDK II veröffentlicht. EDK II ist eine wichtige Grundlage für UEFI-Firmware und wird auch für virtuelle UEFI-Firmware verwendet. Betroffen ist der PXE-Treiber im Modul NetworkPkg/UefiPxeBcDxe. Die Projektmeldung stuft die Lücke mit 9,5 von 10 Punkten nach CVSS 4.0 ein. Red Hat bewertet sie für den eigenen Kontext mit 8,8 nach CVSS 3.1. Die Zahlen unterscheiden sich also nicht wegen zweier verschiedener Fehler, sondern wegen unterschiedlicher Bewertungssysteme und Einsatzbedingungen.

Beim PXE-Boot lädt ein Rechner sein Startprogramm über das Netzwerk. Der UEFI-Treiber verarbeitet dabei unter anderem ICMP-Fehlermeldungen. In einem internen Speicherfeld stehen dafür 504 Byte zur Verfügung. Durch fehlerhafte Längen- und Offsetberechnungen können größere Datenmengen über diese Grenze hinaus kopiert werden. Das ist ein klassischer Buffer Overflow.

Laut TianoCore kann der Fehler einen Netzwerkstart zum Absturz bringen. Ein Angreifer, der die konkrete Firmware-Ausführung ausreichend kennt, könnte außerdem manipulierte Daten als Code im DXE-Abschnitt des Bootvorgangs ausführen lassen. Das passiert vor dem Start von Linux oder Windows und vor den üblichen Prüfungen durch Secure Boot oder Measured Boot.

Warum ist die UEFI-Lücke so gefährlich?

Sicherheitsprogramme und Betriebssystem-Firewalls schützen vor allem die laufende Maschine. Beim Start sind sie noch nicht aktiv. Gelingt die Codeausführung in der Firmwarephase, befindet sich der Angreifer an einer besonders privilegierten Stelle. Daraus folgt aber nicht, dass jedes Gerät automatisch übernommen werden kann: Für einen erfolgreichen Angriff müssen die verwundbare Firmware, ein tatsächlicher PXE-Start, die Zustellung des präparierten Pakets und passende technische Voraussetzungen zusammenkommen.

Wichtig ist auch die Trennung zwischen bestätigter Möglichkeit und beobachtetem Angriff. Der Hersteller beschreibt eine technisch mögliche Codeausführung. Ein öffentlich bestätigter massenhafter Missbrauch dieser konkreten Lücke war in den geprüften Primärquellen zum Redaktionsstand nicht dokumentiert. Ein hoher CVSS-Wert ist kein Beleg für bereits erfolgte Angriffe.

Welche Server, PCs und virtuellen Maschinen sind betroffen?

Eine allgemeine Liste aller betroffenen Mainboards gibt es derzeit nicht. Die Schwachstelle steckt im EDK-II-PXE-Code; ob ein bestimmter Server diesen Code tatsächlich verwendet, hängt vom Firmware-Hersteller, der Version und der Konfiguration ab. Deshalb wäre die Behauptung, sämtliche Server oder alle Proxmox-Hosts seien verwundbar, falsch.

Besonders relevant sind Umgebungen, in denen Rechner regelmäßig über PXE installiert, neu aufgesetzt oder gerettet werden. Das betrifft beispielsweise Rechenzentren, Provisioning-Server, Schulungsräume und manche Recovery-Systeme. Auch ein Gerät, das nur als Rückfalloption Netzwerkboot aktiviert hat, sollte geprüft werden. Das Risiko entsteht nicht allein dadurch, dass ein Netzwerkkabel steckt, sondern durch die Ausführung des anfälligen PXE-Treibers während des Bootvorgangs.

Für gewöhnliche Desktop-PCs und Homeserver, die ausschließlich von SSD oder NVMe starten und keinen PXE-Boot ausführen, beschreibt Red Hat keine Exposition über diesen Fehlerpfad. Trotzdem kann es sinnvoll sein, ungenutzte Netzwerkstartoptionen vorsorglich zu deaktivieren und Firmware-Updates zu beobachten.

Proxmox und OVMF: Was bedeutet CVE-2026-97631 für virtuelle Maschinen?

Bei Proxmox musst du zwei Ebenen unterscheiden: die physische Firmware des Hosts und die virtuelle UEFI-Firmware einzelner VMs. Proxmox selbst ist nicht automatisch verwundbar, nur weil dort virtuelle Maschinen laufen. Für VMs kann OVMF relevant sein: Diese UEFI-Firmware basiert auf EDK II. Red Hat nennt virtualisierte UEFI-Gäste ausdrücklich als möglichen Einsatzbereich des betroffenen Codes.

Eine VM mit OVMF, die per PXE startet, sollte deshalb geprüft werden. Eine VM, die regulär von einer virtuellen Festplatte bootet und gar keinen Netzwerkstart ausführt, ist nicht allein wegen des installierten OVMF-Pakets während ihres normalen Betriebs über diesen PXE-Angriffsweg erreichbar.

Prüfe in der Proxmox-Oberfläche bei der betreffenden VM unter Optionen die BIOS-Einstellung und die Boot-Reihenfolge. Steht ein Netzwerkgerät vor dem Systemlaufwerk oder ist PXE für Installation beziehungsweise Recovery vorgesehen, gehört diese VM auf deine Prüfliste. Eine Netzwerkkarte in der VM ist für sich genommen noch kein Beweis für einen PXE-Start.

Schnellcheck: So prüfst du dein System ohne Risiko

Beginne mit einer Bestandsaufnahme statt mit hektischen Änderungen. Dokumentiere, welche physischen Hosts und virtuellen Maschinen überhaupt Netzwerkboot benötigen. Kontrolliere dann die UEFI- beziehungsweise BIOS-Bootreihenfolge und notiere Firmware-Hersteller sowie Versionsstand. Bei produktiven Servern solltest du jede Änderung am Bootpfad zuerst in einem Wartungsfenster planen.

1. Boot-Reihenfolge im UEFI prüfen

Suche nach Einträgen wie PXE, Network Boot, IPv4 Network Boot, IPv6 Network Boot oder UEFI Network Stack. Die Bezeichnungen unterscheiden sich je nach Hersteller. Wenn du den Netzwerkstart nicht nutzt, kannst du ihn nach Prüfung deiner Recovery-Strategie deaktivieren. Das ist eine vorbeugende Maßnahme aus dem beschriebenen Angriffspfad, kein vom Hersteller garantierter vollständiger Workaround.

2. Proxmox-VMs gezielt kontrollieren

Öffne die Proxmox-Weboberfläche und kontrolliere bei VMs mit OVMF die Startreihenfolge. Bei Bedarf zeigt der Befehl qm config 101 die Konfiguration der Beispiel-VM mit ID 101. Ersetze die ID durch die deiner eigenen VM. Achte auf bios: ovmf sowie auf den boot:-Eintrag. Dieser Befehl liest nur Konfigurationsdaten und ändert nichts.

3. Installierte UEFI-Pakete dokumentieren

Auf Debian-basierten Systemen kannst du mit dpkg -l | grep -E 'ovmf|edk2' nach installierten OVMF- oder EDK-II-Paketen suchen. Ein Treffer zeigt, dass solche Komponenten installiert sind, aber nicht, dass eine konkrete VM verwundbar ist. Ein fehlender Treffer beweist umgekehrt nicht, dass die physische Mainboard-Firmware unbetroffen ist. Für den Host ist die Sicherheitsmeldung des Hardware-Herstellers maßgeblich.

4. Provisioning-Netze absichern

Wenn PXE benötigt wird, betreibe es möglichst in einem getrennten Provisioning-VLAN und begrenze, welche Systeme das Bootnetz erreichen können. Prüfe außerdem, ob ICMP-Verkehr aus nicht vertrauenswürdigen Netzen während des Bootvorgangs zugestellt werden kann. Pauschales Blockieren aller ICMP-Nachrichten ist keine universelle Lösung und kann Netzwerkdiagnose oder andere Funktionen beeinträchtigen.

Gibt es schon ein Update für CVE-2026-97631?

Ein Quellcode-Fix wurde am 15. Oktober 2026 in den EDK-II-Master-Zweig übernommen. Das bedeutet nicht, dass bereits ein passendes BIOS-Update für deinen Server bereitsteht. Die offizielle TianoCore-Sicherheitsmeldung nennt zum geprüften Stand weiterhin keine veröffentlichte gepatchte EDK-II-Version. Auch Hersteller und Linux-Distributionen müssen die Korrektur erst in ihre jeweiligen Firmware- oder OVMF-Pakete übernehmen.

Kontrolliere deshalb gezielt die Sicherheitsseiten deines Mainboard- beziehungsweise Server-Herstellers sowie die Paketinformationen deiner Distribution. Bei virtuellen Maschinen sind aktualisierte OVMF-Pakete relevant, bei physischen Geräten ein passendes UEFI-/BIOS-Update. Installiere keine Firmware aus unbekannten Quellen. Vor jedem Firmware-Update gehören ein geprüftes Backup, eine stabile Stromversorgung und ein klarer Wiederherstellungsplan dazu.

Helfen Secure Boot, TPM oder eine Linux-Firewall?

Secure Boot und TPM bleiben sinnvolle Schutzmaßnahmen. Für diese spezielle Schwachstelle reichen sie jedoch nicht aus, weil der fehlerhafte Treiber bereits vor der Betriebssystemprüfung aktiv sein kann. Auch eine Firewall innerhalb von Linux oder Windows kann keine Pakete filtern, die die Firmware vor dem Betriebssystemstart verarbeitet. Ein vorgeschaltetes Netzwerkgerät und ein sauber getrenntes Provisioning-Netz sind hier die passendere Ebene für zusätzliche Kontrollen.

Du solltest Secure Boot deshalb keinesfalls abschalten. Es schützt weiterhin vor anderen Bedrohungen, auch wenn es den hier beschriebenen PXE-Fehler nicht verhindert.

Drei typische Missverständnisse

Erstens: '9,5 von 10 bedeutet, dass jeder PC sofort gehackt werden kann.' Nein. Der Wert beschreibt die technische Schwere, nicht die Wahrscheinlichkeit für dein konkretes System. Zweitens: 'Proxmox ist betroffen, weil OVMF installiert ist.' Ebenfalls nicht zwingend. Entscheidend sind Firmware, Netzwerkboot und die konkrete Ausführung. Drittens: 'Ein Patch auf GitHub bedeutet, mein BIOS ist bereits sicher.' Nein. Zwischen Quellcodekorrektur und einem getesteten Herstellerupdate können Wochen liegen.

Was ich Administratoren jetzt empfehle

Für einen privaten Homeserver, der zuverlässig von seiner NVMe startet, ist der erste Schritt eine einfache Kontrolle der UEFI-Bootreihenfolge. Wenn Netzwerkboot nicht benötigt wird, deaktiviere ihn nach Prüfung deiner Rettungsoptionen. Wer PXE produktiv einsetzt, sollte die betroffenen Systeme inventarisieren, das Provisioning-Netz isolieren und Herstellerhinweise aktiv verfolgen. Prüfe zusätzlich virtuelle Maschinen mit OVMF und PXE, statt pauschal alle VMs als betroffen einzustufen.

Das ist die sinnvolle Reihenfolge: erst die tatsächliche Exposition feststellen, dann die Angriffsfläche reduzieren und anschließend ein geprüftes Firmware-Update installieren, sobald der zuständige Hersteller es bereitstellt. Ein ungeprüfter BIOS-Flash ist keine angemessene Reaktion auf eine allgemeine Warnmeldung.

Häufige Fragen zu CVE-2026-97631

Ist mein Proxmox-Server automatisch betroffen?

Nein. Es kommt darauf an, ob die physische Firmware den verwundbaren EDK-II-Code verwendet und ob der betroffene PXE-Netzwerkstart ausgeführt wird. Bei VMs ist zusätzlich die OVMF-Version und die Bootkonfiguration relevant.

Kann ich die Lücke mit einem normalen Linux-Update schließen?

Nicht unbedingt. Die physische UEFI-Firmware wird in der Regel vom Gerätehersteller aktualisiert. Für virtuelle UEFI-Firmware kann dagegen ein Paketupdate des Hypervisors beziehungsweise der Distribution erforderlich sein. Prüfe immer, welcher Teil deiner Umgebung betroffen ist.

Reicht es, PXE zu deaktivieren?

Für Geräte, die keinen Netzwerkboot benötigen, reduziert das Abschalten dieses Angriffswegs die Exposition deutlich. Es ersetzt aber nicht die spätere Installation eines passenden Sicherheitsupdates und ist keine pauschale Aussage über andere Firmware-Schwachstellen.

Weiterführende Luftpoet-Anleitungen

Wenn du deine Virtualisierungsumgebung besser verstehen möchtest, lies Mein Homeserver 2026 – Proxmox Setup, Dienste und Architektur.

Für den Einstieg in die Serververwaltung hilft dir außerdem Proxmox Server aufsetzen – Schritt für Schritt.

Wenn du einen bootfähigen Rettungsdatenträger brauchst, findest du die Grundlagen im Beitrag Windows Bootstick erstellen.

Quellen und Stand der Sicherheitsmeldung

Primärquelle: TianoCore-Sicherheitsmeldung GHSA-99cj-7hg9-mp4m vom 22. Oktober 2026.

Quellcode-Fix: EDK-II-Pull-Request #13302, am 15. Oktober 2026 übernommen.

Einordnung für virtuelle Maschinen: Red-Hat-Sicherheitsbewertung zu CVE-2026-97631.

Paketstatus: Ubuntu Security Tracker zu CVE-2026-97631.

Redaktioneller Hinweis: Die genannten technischen Risiken und Daten stammen aus den verlinkten Sicherheitsmeldungen. Die Empfehlungen zur Netztrennung und zum Abschalten ungenutzter PXE-Optionen sind defensive Praxismaßnahmen. Ob ein konkretes Gerät betroffen ist und wann ein Herstellerpatch erscheint, muss im Einzelfall überprüft werden.

Neugierig auf mehr?

Auf Luftpoet findest du weitere verständliche Anleitungen zu Linux, Servern, Netzwerken und Sicherheit. Schau regelmäßig vorbei, wenn du dein eigenes Technikuniversum besser verstehen und sicher betreiben möchtest.