Krytyczne luki w PHP. Od porannego alertu do wdrożenia poprawek
W tym case study pokazujemy, jak zespół utrzymania 1000ideas zareagował na krytyczne luki w PHP: od porannego sygnału i podziału zadań, przez ocenę ryzyka przed wydarzeniem klienta, po wieczorne wdrożenia poprawek jeszcze tego samego dnia. Taki przebieg warto znać, ponieważ działający serwis również może wymagać pilnej aktualizacji. Liczą się wtedy dostępność poprawki, znajomość środowiska i jasne ustalenie, kto odpowiada za zmianę.
21 października 2026 zespół PHP opublikował poprawki dwóch krytycznych podatności: CVE-2026-109618 i CVE-2026-109619. W określonych warunkach pozwalały one wykonać kod na serwerze bez logowania. Problem dotyczył samego PHP, więc aktualizacja kodu aplikacji lub wtyczek nie wystarczała.
Przygotowania zaczęliśmy już rano, przed publikacją poprawki. O 8:35 na kanale zespołu pojawił się sygnał o zapowiadanym zagrożeniu, a o 11:34 powstały zadania dla poszczególnych projektów. Ustalaliśmy, których aplikacji dotyczy problem i kto odpowiada za aktualizację.
Jeszcze przed publikacją łatki poinformowaliśmy klientów, że prowadzimy działania związane z zagrożeniem. Komunikacja z klientami towarzyszyła więc przygotowaniom do aktualizacji.
Pierwsze trzy godziny: od sygnału do zadań
Między pierwszym sygnałem a utworzeniem zadań minęły 2 godziny i 59 minut. To czas zorganizowania prac. Samo wdrożenie wymagało jeszcze dostępnej poprawki, sprawdzenia środowiska i decyzji dla konkretnej aplikacji.
Godziny na osi podano w czasie polskim (CEST). Poprawki wdrażaliśmy jeszcze wieczorem 21 października.
Jedno zagrożenie, różne odpowiedzialności
Zakres prac obejmował aplikacje dedykowane, WordPress i Magento. Aktualizacja zależała od sposobu uruchamiania systemu. W aplikacjach kontenerowych należało uwzględnić obraz PHP i konfigurację w repozytorium, a w pozostałych środowiskach także zakres dostępu administratora.
Rozdzieliliśmy prace między deweloperów odpowiedzialnych za projekty oraz administratora. Dla części stron aktualizację przypisano dostawcy hostingu. Rozróżnienie tych ról było potrzebne, żeby ustalić, kto wykonuje zmianę, a kto powinien potwierdzić jej zakończenie.
Wieczorne wydarzenie zmieniało ocenę ryzyka
Na jednej z platform klient miał tego samego dnia zaplanowane wydarzenie o 19:00. Zespół oceniał dwa ryzyka: pozostawienie podatnego środowiska i destabilizację aplikacji tuż przed wydarzeniem. W rozmowie uwzględniono możliwą krótką niedostępność podczas zmiany oraz czas potrzebny na sprawdzenie systemu.
Dostępność poprawki również zależała od kanału dystrybucji. O 17:15 deweloper raportował, że oczekiwany obraz Dockera z łatą nie jest jeszcze dostępny. Publikacja poprawki przez autorów PHP nie oznaczała, że można było od razu pobrać ją w każdym używanym obrazie. Jeszcze tego samego wieczoru realizowaliśmy wdrożenia poprawek.
Wdrożenia poprawek: od testów do produkcji
Prace obejmowały również przebudowę PHP z oficjalną łatą zespołu bezpieczeństwa PHP. W udokumentowanym przebiegu aktualizacji poprawkę sprawdzono najpierw na środowisku testowym, a następnie wdrożono na produkcję. Przed tą zmianą wykonano kopię bazy danych.
Dodatkowo wyłączono mechanizm śledzenia postępu wysyłania plików, wykorzystywany przez jedną z potwierdzonych ścieżek ataku. Według raportu samo wysyłanie plików i dotychczasowe limity ich wielkości pozostały bez zmian. Zmiana konfiguracji uzupełniała oficjalną łatę; sama nie usuwała całego problemu.
Co ten przypadek mówi o utrzymaniu aplikacji
Aplikacja może działać poprawnie z punktu widzenia użytkownika, a jej środowisko wymagać pilnej aktualizacji. W tym przypadku trzeba było ustalić zakres zagrożenia, przypisać odpowiedzialność i uwzględnić kalendarz klienta oraz dostępność poprawek.
Ustaliliśmy również, że po wdrożeniu deweloper przekazuje informację do osoby prowadzącej projekt, żeby klient otrzymał potwierdzenie wykonanych działań. W opisie tego przypadku oddzielamy decyzje, raporty wdrożeń i aktualizacje realizowane przez hosting.
Sposób aktualizacji dopasowywaliśmy do środowiska, dostępnych uprawnień i kanału dystrybucji poprawki.
Kto odpowiada za pilne aktualizacje Twojego systemu?
Jeśli ta odpowiedzialność nie jest ustalona, warto zacząć od przeglądu aplikacji, jej zależności i środowisk.
Źródła techniczne
Przebieg działań odtworzyliśmy na podstawie wewnętrznych zapisów zespołu, raportu dewelopera i potwierdzenia terminu wieczornych wdrożeń. Stan opisu: 23 października 2026. Nazwy klientów oraz szczegóły ich infrastruktury zostały pominięte.
