Wprowadzenie do problemu / definicja
W ekosystemie firmware ujawniono krytyczną podatność związaną z projektem EDK II, czyli referencyjną implementacją UEFI wykorzystywaną przez wielu producentów sprzętu i dostawców oprogramowania układowego. Problem dotyczy ścieżki rozruchu sieciowego PXE i może umożliwić wykonanie kodu jeszcze przed uruchomieniem systemu operacyjnego oraz przed pełnym zastosowaniem mechanizmów ochronnych, takich jak Secure Boot.
To szczególnie istotne zagrożenie dla środowisk serwerowych, centrów danych oraz platform provisioningowych, gdzie rozruch sieciowy pozostaje ważnym elementem automatyzacji wdrożeń, odzyskiwania systemów i zarządzania infrastrukturą.
W skrócie
Podatność otrzymała oznaczenie CVE-2026-97631 i ocenę 9.5/10. Jej źródłem jest przepełnienie bufora w kodzie PXE projektu EDK II, obecne od listopada 2010 roku.
Atakujący znajdujący się w odpowiednim segmencie sieci i mający możliwość oddziaływania na host podczas krótkiego okna rozruchu PXE może doprowadzić do awarii procesu startowego, a w bardziej zaawansowanym scenariuszu także do uruchomienia własnego kodu w kontekście firmware.
- brak wymogu wcześniejszego uwierzytelnienia,
- atak ograniczony do środowisk korzystających z PXE,
- możliwość działania przed załadowaniem systemu operacyjnego,
- wysokie znaczenie dla serwerów bare metal i środowisk data center.
Kontekst / historia
EDK II stanowi podstawę wielu implementacji UEFI dostarczanych przez producentów platform i niezależnych vendorów BIOS/UEFI. Oznacza to, że pojedynczy błąd w projekcie referencyjnym może trafić do szerokiego łańcucha dostaw firmware i utrzymywać się w produktach wielu dostawców przez długie lata.
Analiza historii zmian wskazuje, że podatny fragment logiki został wprowadzony do kodu w listopadzie 2010 roku. Luka mogła więc pozostawać niewykryta przez około 16 lat. Jej ujawnienie pokazuje, jak trudne pozostaje wykrywanie błędów w komponentach pre-boot oraz jak duże znaczenie ma bezpieczeństwo oprogramowania układowego w nowoczesnej infrastrukturze.
Dodatkowo przypadek ten wpisuje się w szerszy trend podatności dotyczących łańcucha startowego, w których problem nie ogranicza się do samego systemu operacyjnego, lecz dotyczy wcześniejszych etapów uruchamiania urządzenia.
Analiza techniczna
Rdzeniem podatności jest błąd typu buffer overflow w implementacji stosu PXE w EDK II. Podczas rozruchu sieciowego komponent firmware przetwarza komunikaty sieciowe, w tym komunikaty ICMP oraz informacje statusowe zwracane przez infrastrukturę sieciową.
Dane wejściowe są kopiowane do bufora o stałym rozmiarze 504 bajtów. Problem wynika z niewłaściwej walidacji długości danych zarówno w ścieżce IPv4, jak i IPv6. W praktyce odpowiednio spreparowany pakiet większy niż przewidziany rozmiar może doprowadzić do nadpisania pamięci sąsiadującej z buforem.
Najprostszy efekt takiego działania to przerwanie procesu rozruchu i odmowa usługi na etapie startu systemu. Znacznie groźniejszy wariant zakłada jednak przygotowanie exploitu dopasowanego do konkretnej kompilacji firmware, co może umożliwić przejęcie przepływu sterowania i wykonanie kodu atakującego.
Kluczowe znaczenie ma tutaj moment ataku. Jeżeli wykonanie kodu nastąpi na etapie firmware, przeciwnik uzyskuje pozycję uprzywilejowaną względem systemu operacyjnego i części mechanizmów ochronnych łańcucha rozruchu. Nawet jednorazowe wykonanie kodu może wystarczyć do dalszego osadzenia złośliwych komponentów lub manipulacji procesem startowym.
Konsekwencje / ryzyko
Najbardziej bezpośrednią konsekwencją jest możliwość wywołania awarii procesu uruchamiania. W środowiskach wysokiej dostępności może to skutkować opóźnieniami we wdrożeniach, problemami z automatycznym provisioningiem oraz utrudnieniami w procedurach odtwarzania usług.
Poważniejsze ryzyko wiąże się jednak z wykonaniem kodu w środowisku pre-boot. Taki dostęp może otworzyć drogę do ingerencji w zaufany łańcuch startowy, obchodzenia części zabezpieczeń oraz przygotowania gruntu pod dalszą eskalację działań. W zależności od platformy i sposobu wdrożenia zagrożone mogą być również mechanizmy związane z ochroną sekretów dostępnych podczas startu systemu.
Praktyczne wykorzystanie luki utrudniają pewne czynniki, takie jak konieczność obecności w odpowiedniej pozycji sieciowej, krótki czas ekspozycji podczas rozruchu oraz potrzeba dopasowania ataku do konkretnego buildu firmware. Mimo to podatność pozostaje bardzo istotna, zwłaszcza w środowiskach współdzielonych, administracyjnych i serwerowych.
Rekomendacje
Organizacje powinny w pierwszej kolejności ustalić, czy PXE jest aktywne i rzeczywiście potrzebne operacyjnie. Jeżeli rozruch sieciowy nie jest wymagany, jego wyłączenie w ustawieniach firmware oraz procesach provisioningowych znacząco zmniejsza powierzchnię ataku.
Kolejnym krokiem powinna być inwentaryzacja zależności od EDK II w całym środowisku, obejmująca serwery, platformy OEM, obrazy firmware i systemy odzyskiwania. Niezbędna jest również współpraca z dostawcami sprzętu w celu potwierdzenia dostępności poprawek BIOS/UEFI.
- zidentyfikować systemy korzystające z PXE w produkcji, testach i procedurach DR,
- sprawdzić dostępność aktualizacji firmware od producentów,
- monitorować komunikaty bezpieczeństwa vendorów dotyczące EDK II,
- ograniczyć ruch z segmentów mogących komunikować się z hostami w fazie rozruchu,
- wdrożyć monitoring anomalii sieciowych i nieudanych startów systemów,
- przetestować wpływ wyłączenia PXE na procesy operacyjne przed zmianą w produkcji.
W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto również przeanalizować izolację segmentów provisioningowych. Rozruch sieciowy powinien być traktowany jako obszar o wysokiej wrażliwości, porównywalny z innymi elementami łańcucha zaufania.
Podsumowanie
CVE-2026-97631 pokazuje, że błędy w firmware mogą pozostawać ukryte przez wiele lat, a ich pełne znaczenie staje się widoczne dopiero wtedy, gdy dotyczą krytycznych etapów uruchamiania systemu. W tym przypadku problem obejmuje kod PXE w EDK II i może prowadzić zarówno do zakłócenia rozruchu, jak i do wykonania kodu przed Secure Boot.
Największe znaczenie podatność ma dla środowisk serwerowych wykorzystujących rozruch sieciowy. Dopóki poprawki nie będą szeroko dostępne w gotowych aktualizacjach firmware od producentów, podstawową linią obrony pozostają ograniczenie użycia PXE, segmentacja sieci, inwentaryzacja podatnych platform oraz bieżące śledzenie komunikatów dostawców.