Post-mortem – maj 2026

Maj 2026 był wyjątkowo trudnym miesiącem dla całej branży hostingowej. W ciągu niespełna czterech tygodni odkrytych i opublikowanych zostało sześć poważnych luk bezpieczeństwa w jądrze systemu Linux – część z nich razem z gotowymi narzędziami do ataku, część zanim zdążyły pojawić się oficjalne poprawki. Tempo było bezprecedensowe.

Chcemy powiedzieć wprost jak to wyglądało z naszej strony, co zrobiliśmy i jakie wnioski z tego wyciągnęliśmy.

Co się wydarzyło i jak reagowaliśmy

Koniec kwietnia, początek maja — pierwsza luka. Wieczorem pojawia się publiczny raport o poważnej podatności. Dotyczy mechanizmu kryptograficznego głęboko w jądrze systemu. Błąd jest deterministyczny – działa za każdym razem, bez żadnego wyścigu o zasoby.

W ciągu dwudziestu minut dezaktywujemy odpowiedni komponent na wszystkich hostach. Żaden klient nie korzystał z niego produkcyjnie. Kilka dni później trafia na listę aktywnie eksploatowanych podatności prowadzoną przez amerykańską agencję CISA. U nas wyłączony od pięciu dni.

Początek maja – dwie kolejne, z przebitym embargo. Badacz bezpieczeństwa publikuje dwie podatności zanim zdążyły wyjść poprawki — złamał wcześniej uzgodniony termin ujawnienia. Obie dotyczą podsystemów sieciowych. Reagujemy w analogiczny sposób: dezaktywacja komponentów, weryfikacja że żaden host nie korzysta z nich produkcyjnie.

W tym momencie zaczynamy dostrzegać wzorzec — i zaczynamy pisać automatyzację zamiast łatać ręcznie.

Połowa maja – seria trzech kolejnych. W ciągu tygodnia pojawiają się jeszcze trzy podatności, każda w innym podsystemie. Jedna z nich to nie eskalacja uprawnień, ale wyciek — błąd który mógłby ujawnić wrażliwe dane systemowe nieuprzywilejowanemu użytkownikowi. Ta ostatnia wymaga aktualizacji jądra, nie tylko dezaktywacji komponentu.

Każda z tych podatności mitygowana w ciągu godzin od publikacji.

Dodatkowe wyzwanie: cztery wersje kernela jednocześnie

W tym samym czasie – dwa tygodnie przed pierwszą z podatności – wyszła nowa główna wersja jądra Linux (7.0). Przez cały maj równolegle utrzymywane były cztery aktywne gałęzie systemu. Każda poprawka musiała być śledzona i wdrażana osobno dla każdej z nich, bo nie zawsze pojawiały się równocześnie.

To jeden z powodów dla których dodaliśmy do naszej automatyzacji osobny krok weryfikujący czy system faktycznie działa już na zaktualizowanym jądrze — samo zainstalowanie pakietu nie wystarczy.

Jak zareagowaliśmy – podsumowanie

Każda z podatności była mitygowana w ciągu godzin od publikacji, zanim pojawiły się informacje o aktywnej eksploatacji. Żaden klient nie zgłosił incydentu związanego z tą serią. Według naszej wiedzy żadne środowisko klienckie nie zostało naruszone.

To jednak nie jest powód do samozadowolenia. Seria pokazała, że model reagowania na kolejne luki ma swoje granice – zawsze jesteś o krok za atakującym.

Co zmieniliśmy

Najważniejsza zmiana to odwrócenie logiki: zamiast wyłączać komponenty po tym jak okaże się że są podatne, systematycznie wyłączamy wszystko czego aktywnie nie używamy. Komponenty których nie ma w systemie nie mogą zostać zaatakowane – niezależnie od tego jakie luki zostaną w nich odkryte w przyszłości.

Uzupełnieniem jest rozszerzone monitorowanie i automatyczna weryfikacja po każdej aktualizacji.

Co to oznacza

Nie twierdzimy że jesteśmy nienaruszalni – nikt w tej branży nie może tego powiedzieć uczciwie. Twierdzimy że wyciągnęliśmy wnioski i wdrożyliśmy je jako trwałe zmiany, a nie jednorazowe reakcje na konkretne zdarzenia.

Jeden z kolegów podsumował to najlepiej: zamiast gasić kolejne pożary, postanowiliśmy zabetonować podłogę.

Jeśli macie pytania dotyczące bezpieczeństwa waszych środowisk – jesteśmy do dyspozycji przez standardowe kanały wsparcia.