Krótko: Po PHP2Shell kolejne komunikaty o PHP są prawdopodobne, ponieważ już dwa dni po poprawce pojawiła się trzecia wskazówka, pełny komunikat (advisory) jeszcze się nie ukazał, a dystrybucje dostarczają swoje pakiety etapami. Kto teraz ustali stałą procedurę obserwacji, oceny, aktualizacji i restartu, zareaguje na następną nową lukę bezpieczeństwa PHP w godzinach, a nie w dniach.
Poprawka nie była końcem historii
21 października 2026 projekt PHP zamknął obie krytyczne luki CVE-2026-109618 i CVE-2026-109619 wersjami 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wielu odpowiedzialnych odhaczyło sprawę. Dwa dni później, 23 października, pojawiła się jednak kolejna wskazówka php.net dotycząca CVE-2026-115560.
Ta trzecia wskazówka dotyczy tylko nietypowej konfiguracji sesji. Pokazuje jednak wzorzec znany z dużych przypadków bezpieczeństwa: gdy jakiś komponent nagle staje w świetle reflektorów, wielu fachowców jednocześnie przygląda mu się dokładniej. Czy wyniknie z tego więcej luk, dziś nikt nie wie. Prawdopodobne jest jednak, że strumień wiadomości się nie urwie.
Dla Państwa jako operatora oznacza to: proszę uwzględnić w planach kolejne komunikaty, zamiast być zaskakiwanym przez każdy z nich. Dotychczasowy przebieg wydarzeń podsumowuje nasza chronologia PHP2Shell.
Dlaczego kolejne komunikaty są prawdopodobne
Poniższa ocena opiera się na publicznie znanych faktach. Nie jest prognozą konkretnych luk.
- Advisory jeszcze się nie ukazało. php.net traktuje CVE-2026-115560 w regularnym cyklu wydawniczym i zapowiedział opublikowanie pełnego advisory wraz z następnym wydaniem. Do tego czasu rozwiązaniem jest
session.upload_progress.enabled=0. - Szczegóły były wcześnie publiczne. Według kilku doniesień szczegóły stały się znane przed upływem embarga. Według doniesień watchTowr odtworzył CVE-2026-109618 według własnych informacji. Takie prace prowadzą często do kolejnych pytań o sąsiednie fragmenty kodu.
- Dystrybucje dostarczają etapami. Ubuntu zaopatrzyło 21 października aktualne wydania w USN-8948-1, a w USN-8948-2 dostarczyło poprawki dla 14.04 do 20.04 przez Ubuntu Pro. Red Hat napisał w swoim biuletynie, że niektóre aktualizacje są dostępne, a kolejne są w przygotowaniu.
- Dotknięta jest wersja rozwojowa. Według php.net także PHP 8.6.0 RC4 zawiera poprawki. Kto testuje wersje wstępne, musi dostosować także te środowiska.
- Stare wersje pozostają otwarte. Dla PHP 8.1 i starszego istnieją tylko minimalne backporty źródłowe. Każdy dostawca, który dostarcza takie wersje, zgłasza swój stan samodzielnie i we własnych terminach.
Jak nowa luka bezpieczeństwa PHP do Państwa dociera
Komunikaty przychodzą różnymi drogami i z różną wiarygodnością. Kolejność jest niemal zawsze taka sama: najpierw projekt PHP, potem dystrybucje i dostawcy hostingu, potem urzędy i media.
| Źródło | Czego się tam dowiedzą | Jak wiarygodne |
|---|---|---|
| php.net | Dotknięte gałęzie, naprawione wersje, środki przejściowe | Źródło pierwotne |
| Ubuntu, Debian, Red Hat | Stany pakietów dla każdego wydania, czas dostarczenia | Źródło pierwotne dla Państwa systemu |
| Dostawcy hostingu i producenci paneli | Stan własnych kompilacji PHP | Wiążące tylko na piśmie |
| BSI, CERT-Bund | Ocena sytuacji, poziom ostrzeżenia, zalecenia | Ocena urzędowa |
| Prasa branżowa i firmy zajmujące się bezpieczeństwem | Obserwacje ataków, liczby, tło | Pomocne, oznaczać jako doniesienie |
Ważna jest różnica między „jest poprawka” a „mój system ma poprawkę”. Pierwsze twierdzenie stoi na php.net. Drugie muszą Państwo udokumentować dla każdego serwera sami.
Proszę subskrybować komunikaty php.net i swojej dystrybucji przez RSS lub listę mailingową i kierować je do wspólnej skrzynki lub kanału, który czyta więcej niż jedna osoba. Urlopy i choroby to najczęstsze powody spóźnionych aktualizacji.
Co przygotować przed następnym komunikatem
Doświadczenie z PHP2Shell pokazuje, gdzie ucieka czas: przy szukaniu serwerów, przy wyjaśnianiu odpowiedzialności i przy zapomnianym restarcie. To wszystko można załatwić wcześniej.
- Inwentarz: Lista wszystkich serwerów i stron z gałęzią PHP, trybem pracy (PHP-FPM, mod_php, LiteSpeed) i źródłem pakietów. Bez tej listy każdy komunikat zaczyna się od szukania. Jak to osiągnąć, opisuje artykuł Inwentarz wszystkich stron i serwerów.
- Odpowiedzialność: Dla każdego systemu jest ustalone, kto łata, kto restartuje i kto zatwierdza. U dostawców hostingu i agencji należy to do umowy.
- Siatka oceny: Trzy pytania wystarczą do pierwszej oceny. Czy nasza gałąź jest dotknięta? Czy używamy dotkniętej funkcji lub trybu pracy? Czy jest poprawka, czy tylko środki przejściowe?
- Droga testowa: Środowisko stagingowe, w którym aktualizację PHP można sprawdzić w krótkim czasie.
- Dowód: Stały format, w którym zapisywane są stan pakietów, trafienie w changelogu i czas restartu.
Jak taka procedura działa jako rutyna, a nie akcja gaśnicza, opisuje artykuł Zarządzanie poprawkami jako proces. Tło dotyczące postępowania projektu PHP z lukami podaje strona Jak projekt PHP traktuje luki bezpieczeństwa.
Własna konfiguracja jako system wczesnego ostrzegania
Część kolejnych komunikatów dotyczy tylko określonych ustawień. CVE-2026-115560 jest tego przykładem: php.net podaje jako warunek, że aplikacja przestawia serializer sesji w czasie działania, gdy aktywny jest upload progress. Aplikacje, które nigdy tego nie robią, nie są według php.net dotknięte.
Kto zna swoją skuteczną konfigurację, może szybciej oceniać takie komunikaty. Proszę więc zapisać dla każdej gałęzi, jakie wartości są ustawione po stronie serwera i które aplikacje mogą je nadpisywać. Pomaga już prosta kontrola aktywnych ustawień:
# Skuteczne wartości wiersza poleceń (konfiguracja webowa może się różnić)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Ustawione wartości w pulach FPM (ścieżka zależna od dystrybucji)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Wiersz poleceń nie musi pokazywać tego, co obowiązuje w kontekście webowym. Jasność dają konfiguracja puli lub VirtualHost oraz, krótko i w zabezpieczony sposób, strona phpinfo.
Kolejna zaleta: kto wie, jakie wartości przejściowe pozostały ustawione z tygodnia PHP2Shell, może po następnym regularnym wydaniu świadomie je sprawdzić. Niektóre ustawienia, na przykład wyłączony upload progress, mogą pozostać na stałe sensowne. Inne, takie jak bardzo ciasne limity przesyłania, warto po uzgodnieniu z działami merytorycznymi znów dostosować do rzeczywistej potrzeby.
Jak konkretnie pomaga PHP SOS?
- Śledzimy komunikaty php.net, dystrybucji i BSI oraz oceniamy nowe wskazówki dla Państwa konkretnych systemów.
- Tworzymy z Państwem inwentarz wszystkich instalacji PHP i ustalamy odpowiedzialności dla każdego serwera.
- W ramach umowy serwisowej bezpieczeństwa instalujemy aktualizacje, restartujemy wszystkie procesy i dokumentujemy stan.
- Przy komunikatach bez poprawki wdrażamy środki przejściowe w sposób niemożliwy do nadpisania i sprawdzamy je później.
Częste pytania
Czy po PHP2Shell pojawiła się już nowa luka bezpieczeństwa PHP?
23 października 2026 php.net opublikował wskazówkę dotyczącą CVE-2026-115560. Wykonanie kodu jest według niej możliwe tylko przy nietypowej konfiguracji sesji. Pełny komunikat (advisory) ma ukazać się wraz z następnym regularnym wydaniem.
Czy po każdym nowym komunikacie muszę działać natychmiast?
Nie każdy komunikat wymaga tego samego pośpiechu. Decydują stopień dotkliwości, to, czy Państwa konfiguracja jest dotknięta, oraz pytanie, czy poprawka jest dostępna. Ustalona procedura pomaga ocenić to w minuty, a nie w dni.
Gdzie najpierw dowiem się o nowych lukach PHP?
Źródła pierwotne to komunikaty na php.net i wskazówki bezpieczeństwa Państwa dystrybucji, na przykład Ubuntu Security Notices, Debian Security Tracker lub Red Hat. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) informuje przez komunikaty ostrzegawcze. Doniesienia medialne są pomocne, ale często późniejsze i mniej dokładne.
Dlaczego dystrybucje czasem zgłaszają się o dni później niż php.net?
Dystrybucje muszą przenieść poprawkę do własnych pakietów, zbudować je i przetestować. Dla starszych wydań może to trwać dłużej lub odbywać się tylko przez oferty dodatkowe. Dlatego warto śledzić oba źródła osobno.