Sophos Firewall: hotfix luki jądra CVE-2026-98432

Sophos udostępnił hotfix jądra dla CVE-2026-98432. Z punktu widzenia eksploatacji najważniejsze jest to, że pobrana aktualizacja chroni firewall dopiero po wymaganym restarcie. Dlatego nawet przy automatycznej dystrybucji hotfixów należy sprawdzić stan instalacji i zaplanować okno serwisowe.

Ten artykuł oddziela techniczny opis luki od konkretnej ścieżki aktualizacji urządzeń Sophos. Stan weryfikacji źródeł: 11 listopada 2026 r. Na podlinkowanych stronach producenta mogą później pojawić się kolejne wersje firmware.

Które wersje Sophos wymagają uwagi?

Dla poniższych produktów i wersji SFOS dostępne są następujące poprawki:

Produkt / wersja	Dostępna poprawka
SFOS 22.0 MR3	Hotfix HF110626.1, wymagany restart
SFOS 23.0 GA	Hotfix HF110626.1, wymagany restart
SFOS 23.0 EAP1	Hotfix HF110626.1, wymagany restart
Inne wersje SFOS	Zweryfikowany komunikat nie wymienia innych wersji docelowych hotfixa; Sophos zaleca aktualizację do 22.0 MR3 lub 23.0
Sophos SD-RED 20 / SD-RED 60	Osobny firmware RED 3.0.012

To tabela dostępnych poprawek, a nie pełna lista wszystkich podatnych kompilacji. Sophos nie publikuje w tym miejscu kompletnej macierzy podatności ze wskazaniem najwcześniejszej i ostatniej podatnej wersji SFOS. Brak wpisu w tabeli nie oznacza więc, że dana wersja jest bezpieczna. Dotyczy to na przykład oceny instalacji z SFOS 21.5 lub 22.0 MR2.

Przed zmianą wersji należy sprawdzić obsługiwaną ścieżkę aktualizacji i zgodność sprzętu. Artykuł o SFOS 22.0 MR3 przedstawia to wydanie serwisowe; przegląd Sophos Firewall v23 opisuje nową wersję główną. Dla środowiska produkcyjnego należy świadomie wybrać odpowiednią wersję oficjalną. To, że EAP1 otrzymuje hotfix, nie jest powodem do przechodzenia na wersję przedpremierową tylko dla tej poprawki.

Jak można wykorzystać lukę w jądrze?

CVE-2026-98432 dotyczy błędu use-after-free w obsłudze IPv4 TCP w jądrze Linux. Jedna ze ścieżek przetwarzania odwołuje się do pamięci, która została już zwolniona. U podstaw leży sytuacja wyścigu, powstająca wskutek następujących równoległych operacji:

Podczas zestawiania połączenia TCP dane opcji IPv4 są przekazywane między wewnętrznymi strukturami gniazd.
Równolegle inny rdzeń procesora może przetwarzać ponownie otrzymany pakiet SYN i przygotowywać odpowiedź SYN-ACK.
Jeśli powiązana struktura zostanie w tym czasie zwolniona, równoległe przetwarzanie może nadal odwoływać się do jej danych opcji.

Sytuacja wyścigu to błąd, którego wystąpienie zależy od kolejności i zbieżności czasowej operacji równoległych. Udany atak wymaga odpowiedniego zbiegu przetwarzania sieciowego i stanu pamięci. Samo zwykłe zestawienie połączenia nie dowodzi więc skutecznego wykorzystania luki.

Według Sophos w określonych warunkach możliwe jest zdalne wykonanie kodu bez logowania, z uprawnieniami jądra. Publicznie opisany test laboratoryjny przeprowadzono na serwerze z nasłuchującym gniazdem Multipath TCP (MPTCP). Nie jest to opublikowany dowód skutecznego przejęcia Sophos Firewall. Nie można też z tego wnioskować, że samo wyłączenie MPTCP usuwa lukę leżącą u podstaw problemu.

Sophos klasyfikuje swój komunikat jako High i podaje różne oceny CVSS: 9,8 według Linux Kernel CNA, 5,9 według Red Hat ze względu na sytuację wyścigu. Zgodnie ze stanem wiedzy opisanym w komunikacie zaktualizowanym ostatnio 6 listopada Sophos nie znał publicznych doniesień o aktywnym wykorzystywaniu luki. Ta informacja odnosi się do konkretnej daty i nie gwarantuje braku ataków.

W praktyce dostępność sieciową i stan poprawek należy oceniać oddzielnie. Ograniczenie dostępu administracyjnego jest zasadne, ale nie dowodzi, że podatna ścieżka przetwarzania w jądrze jest nieosiągalna. Także udane logowanie z MFA nic nie mówi o ochronie przed atakiem niewymagającym logowania.

Instrukcja: instalacja hotfixa na firewallu

1. Przygotowanie prac serwisowych

Przed rozpoczęciem utworzyć aktualną kopię zapasową konfiguracji i ustalić możliwości przywrócenia działania. Dla zdalnych lokalizacji należy zaplanować alternatywny dostęp administracyjny lub dostępność osoby na miejscu. Jest to szczególnie ważne, gdy jedyne połączenie z firewallem prowadzi przez tunel VPN, który zostanie przerwany podczas restartu.

Na potrzeby kontroli po aktualizacji przygotować krótką listę połączeń krytycznych dla działalności: dostęp do Internetu, DNS, VPN site-to-site, dostęp zdalny oraz opublikowane aplikacje. Udany ping po pracach serwisowych nie zastępuje testu działania tych usług.

Jeśli zainstalowana jest inna wersja SFOS niż wymienione powyżej, najpierw zaplanować aktualizację firmware. Obsługę opisuje instrukcja aktualizacji firmware SFOS. Aktualizację wersji i instalację hotfixa zaplanować jako oddzielne etapy.

2. Sprawdzenie pobrania i instalacji

Zalogować się do WebAdmin i w Control center odszukać komunikat o pobranym hotfixie jądra wymagającym restartu.
Jeśli automatyczne hotfixy są wyłączone, otworzyć w CLI 4 – Device Console i włączyć je:
```
system hotfix enable
```
Poczekać na pobranie. Po wymaganej aktualizacji firmware hotfix musi dopiero zostać udostępniony; jego zastosowanie wymaga kolejnego restartu.
Uruchomić firewall ponownie w oknie serwisowym. Ruch sieciowy zostanie w tym czasie przerwany.
Następnie sprawdzić stan w Device Console:
```
system hotfix list
```

Decydujący jest wpis HF110626.1 ze statusem Installed. Sama obecność hotfixa na liście nie wystarcza. W SFOS 23.0 strona Hotfix: Security updates może nadal być pusta mimo zakończonej instalacji; w takim przypadku Sophos zaleca sprawdzenie w CLI.

3. Dokumentacja wyniku

W dokumentacji eksploatacyjnej należy zapisać nazwę urządzenia, wersję SFOS, termin prac serwisowych i zweryfikowany stan hotfixa. Następnie wykonać przygotowane testy połączeń. Pozwala to odróżnić udaną instalację od przywrócenia działania usług biznesowych.

Jeśli hotfixa brakuje lub jego stan pozostaje niejasny, nie uznawać prac za zakończone. Najpierw porównać wersję firmware, ustawienie hotfixów i komunikat o pobraniu. Jeśli problem się utrzymuje, przekazać te informacje wsparciu producenta. Wielokrotne restarty bez nowych ustaleń nie są wiarygodnym sposobem rozwiązywania problemów.

Klaster HA: aktualizacja obu urządzeń

Sophos określa stałą kolejność: sprawdzić komunikat o pobraniu na obu urządzeniach, najpierw uruchomić ponownie urządzenie Auxiliary, poczekać na jego powrót, a następnie uruchomić ponownie urządzenie Primary. Oba urządzenia wymagają hotfixa. Zgodnie z instrukcją polecenie CLI wyświetlające listę hotfixów jest obecnie dostępne tylko na urządzeniu pełniącym rolę Primary.

Urządzenie Auxiliary trzeba uwzględnić również przy zarządzaniu przez Sophos Fusion. Po przełączeniu awaryjnym komunikat może pojawić się ponownie, ponieważ dotyczy drugiego urządzenia, które jest teraz aktywne.

Przed drugim restartem należy dodatkowo sprawdzić, czy partner jest ponownie gotowy do pracy i czy klaster znajduje się w prawidłowym stanie. Para HA nie uzasadnia zapowiadania gwarantowanego braku przerw: w planowaniu należy uwzględnić przełączenie awaryjne i zachowanie sesji. Na zakończenie odnotować oba urządzenia osobno w protokole prac i przetestować aplikacje przez klaster.

Oddzielna aktualizacja SD-RED 20 i SD-RED 60

Hotfix firewalla nie zastępuje aktualizacji RED. Dla SD-RED 20 i SD-RED 60 Sophos wskazuje firmware 3.0.012, opublikowany 5 listopada:

W WebAdmin otworzyć Backup & Firmware > Pattern Updates.
Jeśli firmware SD-RED jest starszy niż 3.0.012, wykonać Update Pattern Now.
Za pomocą Install wdrożyć firmware na podłączonych urządzeniach SD-RED. Podczas instalacji urządzenia uruchamiają się ponownie.

Sophos Firewall Pattern Updates: dostępny firmware RED 3.0.012, wyróżniony przycisk Install — Nie zapomnieć o RED: w Backup & Firmware > Pattern Updates należy wdrożyć dostępny firmware RED na urządzeniach za pomocą Install. Sam hotfix firewalla nie aktualizuje urządzeń SD-RED.

Jako wymagania dotyczące dystrybucji Sophos wymienia SFOS 20.0 MR3 i nowsze lub SFOS 21.0 MR1 i nowsze. Te informacje dotyczą dystrybucji aktualizacji RED i nie należy ich mylić z wersjami docelowymi hotfixa firewalla. Starsze modele RED po zakończeniu wsparcia nie otrzymują tej poprawki.

Po restarcie należy sprawdzić aplikację działającą przez połączenie RED w każdej lokalizacji zdalnej. Przy wielu urządzeniach pomocna jest lista lokalizacji z wersją firmware i wynikiem kontroli: udana aktualizacja jednego urządzenia nie potwierdza stanu wszystkich pozostałych lokalizacji.

Częste pytania dotyczące prac serwisowych

Czy restart bez widocznego komunikatu o hotfixie wystarczy?

Sam restart nie jest wiarygodnym potwierdzeniem instalacji. Do zakończenia prac wymagane jest sprawdzenie statusu HF110626.1. Bez tego potwierdzenia stan instalacji pozostaje nieustalony.

Czy można stosować obejścia dla Linuksa na Sophos Firewall?

W przypadku urządzeń Sophos należy stosować ścieżkę zalecaną przez producenta. Sophos wyraźnie oddziela ogólne wskazówki dla Linuksa od poprawek dotyczących konkretnych produktów. Dlatego nie należy przenosić na urządzenie własnych zmian parametrów jądra ani filtrów pakietów z instrukcji dla Linuksa.