Krótko: Kto chce zlecić aktualizację PHP, potrzebuje czegoś więcej niż nowych pakietów: decydujące są właściwy stan pakietów, restart wszystkich procesów PHP i dowód tego. Dokładnie to zapewnia nasza usługa łatania PHP. Otrzymują Państwo pisemny dowód dla każdego serwera, który mogą Państwo przedstawić wewnętrznie lub osobom trzecim.
Dlaczego sama aktualizacja PHP często nie wystarcza
Od 21.10.2026 dostępne są poprawki dla luk PHP2Shell CVE-2026-109618 i CVE-2026-109619. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca natychmiastową aktualizację. W praktyce widzimy trzy typowe pułapki.
Po pierwsze, numer wersji nie zawsze pokazuje prawdziwy stan. Dystrybucje i dostawcy hostingu czasem wprowadzają backporty; wtedy na przykład Plesk nadal zgłasza 8.2.34, mimo że stan pakietów jest załatany. Po drugie, po instalacji często nadal działają stare procesy PHP. Nowe pliki na dysku nie chronią, dopóki stare workery pracują w pamięci. Po trzecie, na jednym serwerze często równolegle działa kilka wersji PHP i jedna z nich zostaje pominięta.
Zlecenie aktualizacji PHP: naprawione wersje
| Gałąź | Naprawiona od | Stan poprzedni | Uwaga |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | dodatkowo sprawdzić fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | wsparcie kończy się 31.12.2026 |
| PHP 8.1 i starsze | brak oficjalnych aktualizacji | – | tylko minimalne backporty kodu źródłowego dla 7.4, 8.0, 8.1 |
W przypadku pakietów z dystrybucji lub od dostawców hostingu liczy się nie liczba po „PHP”, lecz stan pakietu, który dostawca potwierdza jako załatany. Jak sprawdzić to samodzielnie, opisuje strona Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
Jak konkretnie pomaga PHP SOS?
- Inwentaryzacja: Rejestrujemy wszystkie instalacje PHP na serwerze, tryb pracy (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) oraz to, która strona używa której wersji.
- Instalacja aktualizacji: Instalujemy naprawione wersje ze źródła pakietów Państwa dystrybucji, panelu lub oficjalnego projektu. Dla kontenerów budujemy z Państwem nowe obrazy.
- Restart wszystkich procesów: Całkowicie restartujemy PHP-FPM, Apache, LiteSpeed lub odpowiednie workery i kontrolujemy, że żaden proces nie jest starszy niż aktualizacja. Tło opisuje strona Restart PHP-FPM i wszystkich workerów.
- Kontrola działania: Wywołujemy najważniejsze strony i funkcje, na przykład stronę główną, logowanie, formularze i kasę, oraz sprawdzamy dzienniki błędów.
- Dowód: Otrzymują Państwo dla każdego serwera protokół z wersją, stanem pakietów, czasem restartu i otwartymi punktami.
Typowy krok kontrolny po restarcie wygląda tak:
# Wersja PHP CLI i binarki FPM (ścieżka zależy od systemu)
php -v
php-fpm8.3 -v
# Czas uruchomienia procesów FPM: musi być po aktualizacji
ps -o pid,lstart,cmd -C php-fpm8.3
Przypadki szczególne: panele, kontenery i wiele wersji PHP
Na serwerach z Plesk lub cPanel wersje PHP pochodzą często ze źródeł pakietów panelu, a nie z dystrybucji. Tam sprawdzamy każdą zainstalowaną wersję z osobna, także te, które w danej chwili nie są przypisane do żadnej strony. Nieużywane, przestarzałe wersje usuwamy po uzgodnieniu, aby nie zostały przypadkowo ponownie aktywowane.
W środowiskach Docker i Kubernetes aktualizacja na hoście nie wystarcza. PHP tkwi w obrazie, a lukę zamyka dopiero nowo zbudowany obraz z załatanym stanem bazowym, wdrożony na wszystkie działające kontenery. Sprawdzamy przy tym także, czy starsze obrazy w rejestrach lub wdrożeniach są nadal używane. Szczegóły opisuje strona Łatanie PHP w kontenerach Docker.
W przypadku mod_php PHP działa bezpośrednio w procesie Apache. Zespół PHP ocenia tam ryzyko jako najwyższe. Po aktualizacji należy więc całkowicie zrestartować sam Apache; samo ponowne wczytanie konfiguracji nie zawsze wystarcza.
Co od nas otrzymują Państwo
- protokół łatania dla każdego serwera: zainstalowane pakiety, wersje, źródło, czas
- dowód, że wszystkie procesy PHP zostały zrestartowane
- listę sprawdzonych stron i funkcji
- wskazówki dotyczące systemów, których nie udało się załatać, wraz z uzasadnieniem
- zalecenie dalszej drogi, na przykład w przypadku PHP 8.2 ze względu na bliski koniec wsparcia
Czego potrzebujemy od Państwa
- Dostęp: SSH z uprawnieniami administratora lub dostęp do panelu (Plesk, cPanel itp.)
- Okno serwisowe: kiedy wolno przeprowadzić krótki restart
- Osoba kontaktowa: do pytań i do akceptacji po kontroli działania
- Kopie zapasowe: potwierdzenie, że istnieje aktualna kopia, albo zlecenie jej uprzedniego wykonania
- Wskazówki dotyczące rozwiązań własnych: specjalne rozszerzenia PHP lub konfiguracje, które trzeba uwzględnić
Przy hostingu współdzielonym bez własnego dostępu do serwera nie możemy sami łatać. Pomagamy wtedy Państwu zadać dostawcy hostingu właściwe pytania i ocenić odpowiedź.
Czego nie obiecujemy
Usługa łatania zamyka znaną lukę. Nie odpowiada na pytanie, czy serwer został naruszony przed aktualizacją, i nie usuwa wprowadzonego złośliwego oprogramowania. Jeśli chcą to Państwo wiedzieć, odpowiednim zleceniem jest natychmiastowa pomoc przy PHP2Shell ze szukaniem śladów.
Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji. Wdrażamy tu środki przejściowe i zalecamy migrację na wspieraną wersję. Zapewnienia o kompatybilności z Państwa CMS nie wydajemy z pamięci, lecz sprawdzamy je na podstawie wymagań systemowych producenta.
Częste pytania
Dlaczego mój serwer po aktualizacji nadal pokazuje starą wersję PHP?
Mogą być dwie przyczyny. Albo dystrybucja wprowadziła backport, wtedy numer wersji pozostaje taki sam, mimo że stan pakietów jest załatany. Albo stare procesy PHP nadal działają w pamięci i trzeba je zrestartować.
Które wersje PHP zamykają PHP2Shell?
Luka jest naprawiona w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, opublikowanych 21.10.2026. W przypadku pakietów dystrybucji liczy się stan pakietu, który dostawca potwierdza jako załatany.
Czy aktualizacja może unieruchomić moją stronę?
Aktualizacja w obrębie tej samej wersji głównej, na przykład z 8.3.35 do 8.3.36, jest zazwyczaj niekrytyczna. Konieczny jest jednak krótki restart procesów PHP. Okno czasowe uzgadniamy z Państwem, a następnie sprawdzamy strony.
Czy po poprawce wszystko jest załatwione?
Jeśli chodzi o samą lukę, tak, gdy tylko wszystkie procesy zostaną zrestartowane. Czy przed poprawką ktoś już się włamał, poprawka nie pokazuje. Wymaga to osobnej kontroli.