Krótko: Po aktualizacji PHP muszą Państwo zrestartować PHP-FPM i wszystkie inne usługi, które ładują PHP. Nowe pliki na dysku nie wystarczą, dopóki stare procesy PHP działają w pamięci. Dopiero po restarcie serwer pracuje z poprawionym kodem PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 lub backportem Państwa dostawcy.
Dlaczego trzeba zrestartować PHP-FPM
Aktualizacja pakietu zastępuje pliki na dysku. Procesy, które już działają, mają jednak stary kod programu załadowany do pamięci i pracują z nim dalej. PHP-FPM, Apache z mod_php lub LiteSpeed utrzymują swoje workery często przez wiele dni.
Dla PHP2Shell jest to szczególnie ważne. Luka CVE-2026-109619 wiąże się właśnie ze stanem, który pozostaje między żądaniami w tym samym workerze. Worker ze starym kodem pozostaje podatny, niezależnie od tego, jaka wersja leży na dysku. Według php.net należy więc zrestartować wszystkie workery i procesy.
Niektóre menedżery pakietów restartują usługi przy aktualizacji automatycznie, inne nie. Nie należy na to liczyć, lecz sprawdzić wynik.
Typowy obraz z codzienności: zarządzanie pakietami zgłasza „PHP zaktualizowane”, monitoring nie pokazuje błędów, strona działa. Mimo to stare workery nadal obsługują każde żądanie, bo nikt nie zrestartował usługi. Z zewnątrz tego stanu nie widać. Dlatego sprawdzenie czasów uruchomienia procesów należy do każdej aktualizacji.
Które usługi ładują PHP?
| Tryb pracy | Co zrestartować | Typowe polecenie (nazwy zależą od dystrybucji) |
|---|---|---|
| PHP-FPM | każdą usługę FPM, dla każdej zainstalowanej wersji | systemctl restart php8.3-fpm lub systemctl restart php-fpm |
| Apache z mod_php | Apache | systemctl restart apache2 lub systemctl restart httpd |
| php-cgi | wywołujący serwer WWW lub wrapper FastCGI | zależnie od konfiguracji |
| LiteSpeed | LiteSpeed i procesy lsphp | przez zarządzanie LiteSpeed lub jego usługę |
| FrankenPHP | usługę FrankenPHP lub kontener | systemctl restart frankenphp lub utworzyć kontener na nowo |
| Docker, Kubernetes | utworzyć kontenery na nowo z nowego obrazu | zob. Łatanie PHP w kontenerach Docker |
Przy mod_php obowiązuje: aktualizacja dotyczy samego Apache, ponieważ PHP tkwi w każdym procesie Apache. Dlaczego ten tryb pracy jest szczególnie wrażliwy, wyjaśnia strona Dlaczego mod_php niesie najwyższe ryzyko. Dla LiteSpeed szczegóły znajdą Państwo na stronie LiteSpeed i LSAPI.
Restart PHP-FPM: polecenia
Najpierw proszę znaleźć wszystkie usługi PHP na serwerze. Plesk, cPanel i inne interfejsy mają własne usługi PHP z własnymi nazwami; lista je pokazuje.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Następnie zrestartować każdą znalezioną usługę PHP, a nie tylko pierwszą:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # jeśli zainstalowana jest druga gałąź
sudo systemctl restart apache2 # przy mod_php; rodzina RHEL: httpd
Zalecamy restart zamiast reload. Przy reload proces główny pozostaje; jest to przeznaczone dla zmian konfiguracji. Po aktualizacji bezpieczeństwa chcą Państwo mieć pewność, że każdy proces jest nowy.
Jeśli dodatkowo ustawiono środki przejściowe, takie jak session.upload_progress.enabled=0 lub stałe limity pamięci, one również zaczynają działać dopiero po restarcie. Restart załatwia jedno i drugie w jednym kroku.
Sprawdzenie, że żaden stary worker już nie działa
Proszę porównać czas uruchomienia procesów z momentem aktualizacji. Wszystkie polecenia służą wyłącznie do odczytu.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # wiersz „Active: … since …”
needrestart -r l # Debian/Ubuntu, jeśli zainstalowano
Jeśli proces jest starszy niż aktualizacja, nie został objęty. Częste przyczyny to zapomniana druga gałąź PHP, osobna usługa puli z panelu hostingu lub kontener, który został tylko zrestartowany, zamiast utworzony z nowego obrazu. Czy działa właściwa wersja, pokazuje strona Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
Udokumentowanie restartu
Proszę zanotować dla każdego serwera czas aktualizacji i restartu. Ten moment oddziela czas, w którym serwer był podatny, od czasu po nim. Dla późniejszej kontroli śladów, dla ubezpieczyciela i dla możliwego zgłoszenia na podstawie RODO jest to najważniejszy punkt odniesienia. Proszę też zachować logi serwera od 20 października, jak zaleca prasa branżowa.
Na serwerach z wieloma stronami warto sporządzić krótką tabelę: serwer, usługa, wersja PHP, wersja pakietu, czas restartu i osoba, która zrestartowała. Dzięki temu luki w pokryciu szybko rzucają się w oczy, na przykład pominięta pula lub system testowy, którego nikt nie miał na liście.
Jak konkretnie pomaga PHP SOS?
W ramach usługi łatania PHP przejmujemy aktualizację i restart jako spójny przebieg:
- Ustalenie usług: Znajdujemy wszystkie procesy ładujące PHP, także z paneli hostingowych i kontenerów.
- Kontrolowany restart w uzgodnieniu z Państwem, w odpowiednim momencie i z uwzględnieniem trwających zamówień lub formularzy.
- Kontrola końcowa, że żaden proces nie jest starszy niż aktualizacja, a strona odpowiada normalnie.
- Protokołowanie: wersje, stany pakietów i czasy restartów dla każdego serwera.
Częste pytania
Czy systemctl reload zamiast restart wystarczy?
Dla PHP2Shell zalecamy restart. Reload zwykle wprawdzie restartuje workery, ale proces główny może działać dalej. Przez restart mają Państwo pewność, że nie pozostał żaden proces ze starym kodem. Krótkiej przerwie przeciwstawia się jasny dowód.
Czy po aktualizacji PHP muszę zrestartować cały serwer?
Zazwyczaj nie. Wystarczy zrestartować wszystkie usługi, które ładują PHP: PHP-FPM, Apache przy mod_php, LiteSpeed, FrankenPHP lub dotknięte kontenery. Restart całego serwera to prosty wariant, gdy nie mają Państwo pewności, które usługi używają PHP.
Czy mój dostawca hostingu automatycznie restartuje PHP po aktualizacji?
Zależy to od dostawcy. Proszę zapytać konkretnie, czy po poprawce zrestartowano wszystkie procesy PHP, i kazać sobie to potwierdzić na piśmie.