Logo

Checklista łatania krytycznych CVE

Trzy krytyczne luki ujawnione w październiku 2026 (php2shell w rdzeniu PHP, CVE-2026-110264 w GitLab i luka http2shell w Brotli) mają wspólny wzorzec: są nieuwierzytelnione, o maksymalnej lub niemal maksymalnej wadze, w tym wypadku „załatałem w zeszłym tygodniu” nie znaczy „jestem bezpieczny”. To checklista krok po kroku, której używamy wewnętrznie, aby zamknąć podatności na całej przestrzeni aplikacji oraz infrastruktury, i nie pominąć instancji o których nikt nie pamięta.

Pełna checklista jest poniżej, za darmo do czytania i udostępniania.

Zostaw e-mail, jeśli chcesz też dostać sygnał przy następnej ważnej sprawie bezpieczeństwa, wraz z praktycznymi wskazówkami, jak sobie z nią poradzić. Bez rozmowy sprzedażowej, w każdej chwili można się wypisać, a checklista i tak zostaje otwarta.

Podaj poprawny adres e-mail.
Musisz wyrazić zgodę, żebyśmy mogli dodać Cię do listy.

Administratorem Twoich danych osobowych podanych w tym formularzu jest Devopsity sp. z o.o (al. Zwycięstwa 96/98, 81-451 Gdynia). Twój adres e-mail ... Czytaj więcej

1. Zinwentaryzuj każdą narażoną powierzchnię

Nie załatasz tego, czego nie wypisałeś. Dla każdej technologii wypisz każdą instancję, w tym te łatwe do przeoczenia.

  • PHP: każdy host, kontener i zarządzane środowisko serwujące PHP, z dokładną wersją, którą faktycznie serwuje warstwa WWW (PHP-FPM / mod_php), nie tylko CLI. Uwzględnij staging, panele administracyjne i stare serwery.
  • GitLab: każda instancja self-managed, w tym repliki Geo, staging, serwery DR i demo. (GitLab.com i Dedicated są już załatane.)
  • Front HTTP: reverse proxy, load balancery i CDN terminujące lub re-kodujące ruch (ścieżka http2shell / Brotli).
  • Zapomniana instancja dostępna z internetu na podatnej wersji to pełne, nieuwierzytelnione wejście. Pełena inwentaryzacja to właściwy rezultat tego kroku.

2. Potwierdź wersję, którą każde środowisko faktycznie serwuje

  • PHP: sprawdź php-fpm -v (warstwa WWW), a nie tylko php -v (CLI): potrafią się różnić.
  • GitLab: odczytaj /opt/gitlab/embedded/service/gitlab-rails/VERSION (pakiet/Docker), kolumnę APP VERSION w Helm albo GET /api/v4/version.
  • Zanotuj wersję przed i po dla każdej instancji. Audytorzy (ISO 27001 A.8.8, SOC 2 CC7.1) będą oczekiwać datowanego zapisu.

3. Zaktualizuj do wersji z poprawką dla swojej gałęzi

  • PHP: wspierane gałęzie (8.2–8.5) idą na załataną wersję (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) i restart PHP-FPM. PHP 8.1 i starsze są po end-of-life i nie dostaną poprawki w głównych repozytoriach - sprawdź backporty: rozważ aktualizację lub migrację do nowszej aplikacji.
  • GitLab: zaktualizuj w obrębie gałęzi minor (19.5→19.5.1, 19.4→19.4.3, 19.3→19.3.6, 19.2→19.2.9, 19.1→19.1.9, 19.0→19.0.10, 18.11→18.11.13). Pułapka z 12 października: jeśli łatałeś wtedy (19.4.2/19.3.5/19.2.8), nadal jesteś podatny na CVE-2026-110264 i potrzebujesz wersji o jeden patch wyżej. 18.10 i starsze nie mają załatanego wydania: przejdź na wspieraną gałąź.
  • Warstwa HTTP: zastosuj poprawkę producenta dla ścieżki Brotli/dekompresji i zrestartuj proxy.
  • Przypnij dokładne wersje na całej flocie, żeby każdy węzeł wylądował na tym samym buildzie.

4. Uważaj na haczyki

  • GitLab 19.4.3 i 19.3.6 zawierają migracje bazy danych: serwer jedno-nodowy pozostaje niedostępny do ich zakończenia; wielo-nodowy może użyć procedury zero-downtime.
  • Dla żadnej z trzech luk nie ma pewnego obejścia poza załataniem lub wyłączeniem hosta. WAF może przytępić część podatności, ale nie zastępuje poprawki, bo wyzwalacz jest obsługiwany zanim zadziała Twoja aplikacja.
  • Wersje EOL (PHP ≤ 8.1, GitLab ≤ 18.10) to te, które zmieniają łatkę w projekt migracji. Zaplanuj je osobno; nie zostawiaj ich publicznych i nietkniętych.

5. Zweryfikuj i sprawdź czy podatności zostały wyeliminowane skutecznie.

  • Po załataniu ponownie sprawdź serwowaną wersję na każdej instancji (powtórz krok 2).
  • Potwierdź, że host nie jest już podatny: nieoczekiwane procesy, nowe wpisy cron, zmodyfikowane pliki w katalogu web. Dla GitLaba uruchom opublikowane reguły detekcji na logach.
  • Jeśli znajdziesz ślady udanego ataku, potraktuj host jako skompromitowany i wycofaj go z produkcji, zrotuj też wszelkie sekrety które utrzymywał: zmienne CI/CD, tokeny runnerów, klucze deploy, tokeny dostępu.

6. Zapisz to na potrzeby zgodności

Zachowaj datowany zapis per instancja: wersja przed/po, data łatania, ewentualny downtime, wyniki detekcji i zrotowane sekrety. To Twój dowód dla ISO 27001 (A.8.8 zarządzanie podatnościami, A.8.32 zarządzanie zmianą) i SOC 2 (CC7.1, CC8.1).

Najtrudniejszy w takich zdarzeniach nigdy nie jest ten jeden wspierany serwer, o którym myślisz najpierw: to host po EOL, którego nikt nie pilnuje, i instancja „załatana w zeszłym tygodniu”, która wciąż jest narażona. Jeśli chcesz, żeby ktoś rzucił okiem na Waszą ekspozycję, nasz zespół Bezpieczeństwo i Zgodność może zrobić szybki przegląd; dla hostów po end-of-life, których nie da się po prostu załatać, to rozmowa o migracji i modernizacji.

Contents