Krótko: Kto nadal eksploatuje PHP 8.1 lub starsze, nie otrzymuje od projektu PHP oficjalnych aktualizacji bezpieczeństwa, także dla PHP2Shell. Przejście z PHP 8.1 na wspieraną wersję nie jest więc dodatkiem, lecz właściwym rozwiązaniem. Sprawdzamy Państwa aplikacje, testujemy na kopii, migrujemy w sposób kontrolowany i zabezpieczamy czas do tego momentu.
Dlaczego PHP 8.1 i starsze to teraz ostre ryzyko
Luki PHP2Shell CVE-2026-109618 i CVE-2026-109619 umożliwiają wykonanie kodu bez logowania. Są naprawione w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszego nie ma już oficjalnych aktualizacji, tylko minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1. Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4.
Niektóre dystrybucje i dostawcy hostingu wprowadzają własne backporty. Czy Państwa system do nich należy, musi dla Państwa konkretnego stanu pakietów potwierdzić dostawca. Bez tego potwierdzenia należy zakładać, że serwer jest otwarty. Co to oznacza w szczegółach, opisuje strona PHP 8.1 i starsze: co obowiązuje teraz.
Aktualizacja z PHP 8.1: jaka wersja docelowa?
Celem powinna być wersja, którą projekt PHP nadal wspiera i którą Państwa aplikacja dopuszcza. Aktualny stan wsparcia publikuje php.net na stronie wspieranych wersji. PHP 8.2 kończy się 31.12.2026; przejście na 8.2 byłoby więc tylko krokiem pośrednim z rychłym projektem następczym.
Którą wersję PHP wspiera Państwa CMS lub system sklepowy, sprawdzamy na podstawie wymagań systemowych producenta, na przykład na wordpress.org, shopware.com lub typo3.org, a nie z pamięci. Często najpierw trzeba zaktualizować samo CMS. Stare sklepy to typowy przypadek, zob. Shopware 5: stare sklepy na starej wersji PHP.
Jak konkretnie pomaga PHP SOS?
- Inwentaryzacja i zabezpieczenie: Rejestrujemy wszystkie aplikacje, ich wersję PHP, stan CMS, rozszerzenia i własny kod. Równolegle wdrażamy środki przejściowe wg php.net, aby ryzyko do czasu migracji spadło; szczegóły w WAF i wirtualne łatanie.
- Sprawdzenie kompatybilności: Porównujemy wymagania systemowe producentów, sprawdzamy zależności przez Composer i szukamy w kodzie własnym przestarzałych funkcji. Jak to wygląda przy zależnościach, opisuje strona Sprawdzanie zależności Composer pod kątem luk.
- Test na kopii: Aplikacja działa najpierw w środowisku testowym z nową wersją PHP. Błędy usuwamy tam lub dokumentujemy je dla Państwa agencji.
- Przełączenie z drogą powrotną: Przełączenie na żywo następuje w uzgodnionym oknie serwisowym z aktualną kopią zapasową i ustaloną drogą powrotną.
- Kontrola końcowa: Po przełączeniu sprawdzamy dzienniki błędów i kluczowe funkcje oraz usuwamy starą wersję PHP, jeśli nie jest już potrzebna.
Bezpieczny rzut oka na to, które strony używają której wersji PHP, jest na wielu systemach możliwy przez działające pule FPM:
# Pokaż działające procesy master i pule PHP-FPM
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# Zainstalowane wersje PHP (Debian/Ubuntu)
ls /etc/php/
Aktualizacja do nowej wersji PHP nie usuwa złośliwego oprogramowania, które wcześniej zostało wprowadzone. Jeśli serwer od 17.10.2026 był niezabezpieczony w sieci, do tego należy sprawdzenie pod kątem śladów.
Typowe pułapki przy aktualizacji
Większość problemów przy zmianie wersji PHP jest do przewidzenia, jeśli wie się, gdzie szukać:
- Przestarzałe rozszerzenia: Wtyczki lub moduły, które nie są już utrzymywane, często nie działają na nowszych wersjach PHP. Potrzebują zamiennika lub dostosowania.
- Własny kod: Funkcje, które PHP uznało już za przestarzałe lub usunęło, prowadzą do ostrzeżeń lub przerwań. Ostrzejsze sprawdzanie typów ujawnia stare błędy programistyczne.
- Zależności: Biblioteki dołączone przez Composer częściowo same wymagają nowych wersji i pociągają za sobą kolejne zmiany.
- Rozszerzenia PHP na serwerze: Nie każde rozszerzenie zainstalowane w starej wersji jest automatycznie dostępne dla nowej.
- Zadania cron i wiersz poleceń: Strona działa już na nowej wersji, ale zaplanowane zadania wywołują jeszcze starą wersję PHP.
Kto sprawdzi te punkty wcześniej, skraca przełączenie i unika niespodzianek w działaniu na żywo.
Co Państwo otrzymują i czego potrzebujemy
Otrzymują Państwo zestawienie wszystkich aplikacji z wersją wyjściową i docelową, plan migracji z kolejnością i ryzykami, protokół testów, dokumentację przełączenia oraz listę punktów, które musi jeszcze wykonać Państwa agencja lub programista.
Od Państwa potrzebujemy:
- dostępu do serwera lub panelu oraz dostępu do backendów CMS
- dostępu do kodu źródłowego i repozytorium przy rozwiązaniach własnych
- kontaktu z agencją lub programistą, którzy znają aplikację
- środowiska testowego lub zgody na jego utworzenie
- okien serwisowych i osoby kontaktowej do odbioru
Czego nie obiecujemy
Nie obiecujemy, że każda stara aplikacja będzie działać na nowej wersji PHP bez zmian. W systemach bez dalszego rozwoju może być konieczna większa przebudowa lub zmiana; mówimy o tym otwarcie, gdy tylko się to zarysuje. Stwierdzenia o kompatybilności opieramy na informacjach producentów. A środki przejściowe nie zastępują migracji, a jedynie przeczekują czas. Długoterminowe ryzyka przestarzałych wersji opisuje strona PHP End of Life: ryzyka przestarzałych wersji.
Częste pytania
Czy PHP 8.1 jest dotknięte przez PHP2Shell?
Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4. Dla PHP 8.1 i starszego projekt PHP nie wydaje oficjalnych aktualizacji, jedynie minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1. Niektóre dystrybucje wprowadzają własne backporty, musi to potwierdzić dany dostawca.
Na jaką wersję PHP powinienem przejść?
Na wersję, którą projekt PHP nadal aktywnie wspiera i którą Państwa aplikacja dopuszcza według wymagań systemowych producenta. PHP 8.2 osiąga koniec wsparcia 31.12.2026 i dlatego jako cel jest sensowne tylko warunkowo.
Czy nie mogę po prostu przestawić wersji PHP w panelu hostingu?
Technicznie często da się to zrobić jednym kliknięciem. Czy aplikacja potem nadal działa, zależy od wersji CMS, rozszerzeń i własnego kodu. Bez testu ryzykują Państwo awarie lub błędne funkcje, na przykład w kasie sklepu.
Co jeśli moje CMS nie wspiera nowej wersji PHP?
Wtedy najpierw trzeba zaktualizować CMS, w niektórych przypadkach do nowej wersji głównej. W systemach bez dalszego rozwoju może być konieczna zmiana. Do tego czasu zabezpieczamy serwer środkami przejściowymi.