CVE-2026-97631: krytyczna podatność UEFI w EDK II. Zdalne wykonanie kodu jeszcze przed startem Linuksa

Krytyczna podatność CVE-2026-97631 w komponencie firmware EDK II może umożliwić nieuwierzytelnionemu atakującemu wykonanie kodu podczas uruchamiania systemu przez sieć PXE. Problem dotyczy fazy pre-boot, czyli momentu, w którym Linux nie został jeszcze załadowany, a mechanizmy ochronne systemu operacyjnego nie są aktywne. Błąd otrzymał ocenę CVSS 4.0 na poziomie 9,5.

Podatność w UEFI to szczególnie niebezpieczna kategoria problemów bezpieczeństwa. W przeciwieństwie do typowej luki w aplikacji czy jądrze Linuksa, jej wykorzystanie może nastąpić na etapie uruchamiania komputera. Oznacza to, że aktualizacje systemu operacyjnego, konfiguracja firewalla działającego w Linuxie czy mechanizmy ochrony procesów mogą nie mieć żadnego znaczenia dla samego ataku.

W przypadku CVE-2026-97631 problem dotyczy implementacji obsługi PXE w TianoCore EDK II, wykorzystywanej przez wiele środowisk firmware UEFI.

Czym jest EDK II i dlaczego jego podatność jest tak istotna?

EDK II, czyli EFI Development Kit II, to otwartoźródłowa implementacja środowiska UEFI rozwijana w ramach projektu TianoCore.

UEFI (Unified Extensible Firmware Interface) odpowiada za inicjalizację sprzętu oraz przygotowanie środowiska do uruchomienia systemu operacyjnego. W praktyce firmware wykonuje szereg operacji:

• inicjalizuje procesor i pamięć;
• przygotowuje urządzenia sprzętowe;
• wykrywa dostępne urządzenia rozruchowe;
• uruchamia odpowiednie sterowniki firmware;
• przekazuje kontrolę do bootloadera lub systemu operacyjnego.

EDK II jest wykorzystywane zarówno w sprzęcie fizycznym, jak i w środowiskach wirtualizacyjnych. Przykładem może być firmware UEFI dla maszyn wirtualnych QEMU/KVM, gdzie OVMF jest implementacją opartą na EDK II.

Ważne jest jednak rozróżnienie: podatność nie oznacza, że każdy system Linux wykorzystujący UEFI jest automatycznie narażony. Kluczowe znaczenie ma obecność podatnego komponentu PXE oraz sposób uruchamiania systemu.

CVE-2026-97631 – szczegóły techniczne

Critical – CVSS 9.5

Podatność została opisana jako błąd obsługi komunikatów ICMP podczas uruchamiania komputera przez PXE.

Według analizy technicznej problem znajduje się w sterowniku UefiPxeBcDxe, który obsługuje sieciowy proces bootowania. Sterownik przechowuje odebrane komunikaty ICMP błędów w strukturze zawierającej pole Mode.IcmpError o stałym rozmiarze 504 bajtów.

W uproszczeniu problem wygląda następująco:

1. Firmware uruchamia sterownik PXE.
2. Sterownik oczekuje na komunikaty ICMP związane z obsługą błędów sieciowych.
3. Atakujący wysyła odpowiednio przygotowany komunikat ICMP.
4. Firmware kopiuje dane do bufora o ograniczonej pojemności.
5. Nieprawidłowa kontrola długości danych może doprowadzić do zapisu poza granicami bufora.

Problem dotyczy obsługi ICMP zarówno w IPv4, jak i IPv6.

Dlaczego buffer overflow w firmware jest niebezpieczny?

Buffer overflow, czyli przepełnienie bufora, występuje wtedy, gdy program zapisuje więcej danych, niż przewidziano dla określonego obszaru pamięci.

W przypadku firmware UEFI problem może być szczególnie poważny, ponieważ kod wykonywany jest w środowisku DXE (Driver Execution Environment), jeszcze przed uruchomieniem systemu operacyjnego.

Skutki mogą obejmować:

• awarię procesu bootowania;
• denial of service (DoS);
• uszkodzenie pamięci firmware;
• potencjalne wykonanie kodu przez atakującego.

Według analizy podatności możliwe jest doprowadzenie do wykonania kodu w fazie DXE. Wymaga to jednak odpowiedniego dopasowania ataku do konkretnej wersji firmware.

Nie należy więc interpretować CVSS 9,5 jako dowodu, że dowolny serwer można przejąć jednym pakietem ICMP. Podatność stwarza krytyczne ryzyko w określonych warunkach, ale skuteczna eksploatacja zależy również od konfiguracji i implementacji firmware.

PXE – gdzie pojawia się problem?

PXE (Preboot Execution Environment) pozwala uruchomić komputer przez sieć, bez konieczności korzystania z lokalnego dysku.

Jest to popularne rozwiązanie w:

• centrach danych;
• środowiskach HPC;
• automatycznym provisioningu serwerów;
• instalacjach systemów Linux na dużej liczbie urządzeń;
• infrastrukturze bare-metal;
• środowiskach testowych.

Typowy proces bootowania PXE może wyglądać następująco:

flowchart TD
A["Uruchomienie serwera"] --> B["Firmware UEFI"]
B --> C["Inicjalizacja sterownika PXE"]
C --> D["DHCP: uzyskanie konfiguracji sieci"]
D --> E["Pobranie bootloadera przez sieć"]
E --> F["Uruchomienie bootloadera"]
F --> G["Start jądra Linux"]
G --> H["Uruchomienie systemu operacyjnego"]

CVE-2026-97631 dotyczy etapu przed uruchomieniem bootloadera i jądra Linux.

To oznacza, że atakujący nie musi posiadać konta użytkownika, dostępu SSH ani uprawnień root w systemie operacyjnym.

Wystarczy, że może dostarczyć odpowiednio spreparowane komunikaty ICMP do urządzenia w podatnym momencie bootowania.

Secure Boot nie rozwiązuje tego problemu

Jednym z najważniejszych aspektów podatności jest jej położenie w łańcuchu uruchamiania.

Secure Boot ma za zadanie weryfikować podpisy komponentów uruchamianych podczas bootowania. Chroni przed uruchomieniem nieautoryzowanego bootloadera lub innego komponentu, który nie spełnia określonych reguł zaufania.

CVE-2026-97631 dotyczy jednak sterownika firmware, który działa przed załadowaniem systemu operacyjnego.

W praktyce:

• Secure Boot nie naprawia błędu w sterowniku PXE;
• firewall działający w Linuxie nie filtruje pakietów podczas fazy pre-boot;
• aktualizacja jądra Linux nie zastępuje aktualizacji firmware UEFI;
• system może być podatny nawet wtedy, gdy jego konfiguracja bezpieczeństwa po uruchomieniu jest poprawna.

Nie oznacza to, że Secure Boot jest bezużyteczny. To nadal istotny mechanizm ochronny, ale nie zabezpiecza automatycznie przed błędami w kodzie firmware.

Kogo dotyczy podatność?

Najważniejszym kryterium jest wykorzystanie podatnego EDK II oraz uruchamianie urządzenia przez PXE.

W materiałach Hetznera wskazano dwa główne scenariusze:

Serwery dedykowane

W przypadku serwerów bare-metal ryzyko pojawia się podczas ponownego uruchomienia urządzenia, jeśli wykorzystywany jest podatny firmware i bootowanie PXE.

Działający system nie jest bezpośrednio narażony na wykorzystanie tej podatności w normalnej fazie pracy.

Maszyny wirtualne Cloud

W środowisku Cloud Hetzner wskazał ryzyko podczas uruchamiania Rescue System na maszynach korzystających z UEFI.

To ważne rozróżnienie: zwykła praca uruchomionej maszyny wirtualnej nie jest tym samym co proces bootowania, podczas którego może zostać aktywowany podatny sterownik.

Jak sprawdzić, czy Linux został uruchomiony w trybie UEFI?

W systemie Linux można wykonać:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Jeżeli polecenie zwróci:

UEFI

system został uruchomiony w trybie UEFI.

Jeżeli zwróci:

BIOS

system działa w trybie tradycyjnego bootowania BIOS/Legacy.

Ważne: wynik UEFI nie potwierdza sam w sobie podatności. Nie wskazuje również, czy system korzysta z PXE. To jedynie pierwszy krok w identyfikacji konfiguracji.

Jak ograniczyć ryzyko CVE-2026-97631?

Najważniejsza zasada brzmi: aktualizacja firmware UEFI jest właściwym rozwiązaniem docelowym.

Poprawka upstream została opublikowana w projekcie TianoCore EDK II. Następnie musi zostać zintegrowana z firmware dostarczanym przez producenta płyty głównej, serwera lub platformy wirtualizacyjnej.

1. Sprawdź dostępność aktualizacji firmware

Na serwerze Linux można sprawdzić informacje o firmware:

sudo dmidecode -t bios

Przykładowy fragment wyniku:

BIOS Information
    Vendor: Example Vendor
    Version: 1.2.3
    Release Date: 01/01/2026

W przypadku serwerów dedykowanych należy sprawdzić portal producenta sprzętu lub informacje dostawcy hostingu.

Dla maszyn wirtualnych aktualizacja firmware może być odpowiedzialnością operatora infrastruktury.

2. Wyłącz PXE, jeśli nie jest potrzebne

Jeżeli serwer uruchamia się z lokalnego dysku i nie korzysta z sieciowego bootowania, warto wyłączyć PXE w konfiguracji firmware.

To ogranicza powierzchnię ataku, choć nie zastępuje aktualizacji podatnego firmware.

W przypadku serwerów zarządzanych przez dostawcę hostingu nie zawsze istnieje możliwość samodzielnej zmiany ustawień UEFI. W takim przypadku należy skontaktować się z operatorem.

3. Ogranicz dostęp do sieci bootowania

Jeśli PXE jest wymagane, należy ograniczyć jego wykorzystanie do zaufanej, odpowiednio odseparowanej sieci.

Dobre praktyki obejmują:

• separację VLAN dla provisioningu;
• ograniczenie dostępu do serwerów PXE;
• filtrowanie ruchu ICMP na granicy sieci;
• kontrolę dostępu do infrastruktury zarządzającej;
• ograniczenie możliwości bootowania z nieautoryzowanych źródeł.

Takie środki zmniejszają ryzyko, ale nie gwarantują pełnej ochrony przed podatnością.

4. Tymczasowo ogranicz ICMP podczas rebootu

Hetzner zalecał w przypadku serwerów dedykowanych tymczasowe blokowanie przychodzącego ICMP przy koniecznym restarcie, z wykorzystaniem Hetzner Firewall.

W przypadku ich Cloud infrastruktury wdrożono filtry sieciowe obejmujące między innymi fragmentowane pakiety ICMPv4 oraz określone komunikaty ICMPv4 o rozmiarze co najmniej 768 bajtów.

Nie jest to jednak uniwersalna reguła, którą można bezrefleksyjnie zastosować na każdym serwerze.

ICMP pełni ważne funkcje diagnostyczne i sieciowe. Nie należy globalnie blokować całego ruchu ICMP bez analizy konsekwencji. W szczególności filtrowanie ICMPv6 wymaga ostrożności ze względu na jego znaczenie dla działania IPv6.

Co zrobić, jeśli serwer działa już w produkcji?

Według komunikatów Hetznera działający system nie jest bezpośrednio narażony na wykorzystanie CVE-2026-97631 w normalnej fazie pracy.

Nie oznacza to jednak, że można zignorować problem.

W przypadku infrastruktury, która korzysta z PXE lub UEFI Rescue System, warto:

1. Zidentyfikować podatne urządzenia.
2. Sprawdzić, czy PXE jest faktycznie wykorzystywane.
3. Zweryfikować dostępność aktualizacji firmware.
4. Zaplanować kontrolowany reboot po wdrożeniu poprawki.
5. Tymczasowo ograniczyć dostęp do sieci bootowania.
6. Utrzymywać kopie zapasowe oraz dokumentację procedur awaryjnych.

Nie należy traktować unikania restartów jako trwałego rozwiązania. To wyłącznie środek ostrożności do czasu wdrożenia poprawionego firmware lub odpowiednich zabezpieczeń sieciowych.

Status poprawki i działania dostawców

TianoCore opublikowało poprawkę upstream w ramach PR #13302. Oznacza to, że projekt bazowy otrzymał zmianę eliminującą opisywany problem.

Nie oznacza to jednak, że wszystkie urządzenia korzystające z EDK II są już naprawione.

Proces aktualizacji firmware zwykle wygląda następująco:

1. Poprawka zostaje opublikowana w projekcie upstream.
2. Producent integruje ją z własną wersją firmware.
3. Wykonywane są testy kompatybilności.
4. Producent udostępnia aktualizację dla konkretnej platformy.
5. Administrator wdraża aktualizację zgodnie z procedurą producenta.

W przypadku Hetznera komunikaty z początku listopada 2026 r. wskazywały, że filtry sieciowe zostały wdrożone w infrastrukturze Cloud, natomiast dla serwerów dedykowanych nadal analizowano rozszerzenie zabezpieczeń w sieciach centrów danych.

Filtry te należy traktować jako mitigację, a nie jako zastępstwo poprawionego firmware.

Czy CVE-2026-97631 zagraża zwykłym użytkownikom desktopowego Linuksa?

W typowej konfiguracji komputera domowego, który uruchamia Linuxa z lokalnego dysku, ryzyko jest znacznie mniejsze.

Podatność nie dotyczy bezpośrednio jądra Linux, serwera SSH, przeglądarki internetowej ani standardowej aplikacji użytkownika.

Kluczowe znaczenie ma to, czy firmware wykorzystuje podatny sterownik PXE i czy urządzenie wykonuje sieciowy proces bootowania.

Zwykły użytkownik powinien przede wszystkim:

• aktualizować firmware zgodnie z zaleceniami producenta;
• wyłączyć PXE, jeśli nie jest używane;
• nie ignorować komunikatów bezpieczeństwa producenta sprzętu.

Administratorzy serwerów, środowisk wirtualizacyjnych oraz infrastruktury provisioningu powinni natomiast potraktować problem jako istotny incydent wymagający weryfikacji.

Podsumowanie

CVE-2026-97631 pokazuje, że bezpieczeństwo systemu Linux zaczyna się znacznie wcześniej niż w momencie uruchomienia jądra.

Podatność w EDK II umożliwia potencjalne wykonanie kodu w fazie DXE podczas sieciowego bootowania PXE. Błąd dotyczy obsługi komunikatów ICMP i nieprawidłowego zapisu danych do ograniczonego bufora.

Najważniejsze wnioski:

• CVE-2026-97631 otrzymało ocenę CVSS 4.0 9,5;
• podatność dotyczy firmware EDK II oraz sterownika PXE;
• problem może wystąpić przed uruchomieniem Linuksa;
• Secure Boot nie eliminuje tego rodzaju podatności;
• poprawka upstream została opublikowana, ale jej dostępność zależy od producenta firmware;
• ograniczenie PXE i filtrowanie ruchu sieciowego mogą zmniejszyć ryzyko;
• administratorzy powinni zweryfikować konfigurację UEFI oraz dostępność aktualizacji.

Dla administratorów Linuxa to przypomnienie, że aktualizacje systemu operacyjnego są tylko jednym z elementów bezpieczeństwa. Firmware, bootloader, konfiguracja sieci i procedury odzyskiwania systemu również muszą być uwzględniane w procesie zarządzania podatnościami.