Krótko: Aktualizacja PHP w Plesk jest zakończona dopiero wtedy, gdy każda zainstalowana wersja PHP ma stan z usuniętą luką, wszystkie usługi PHP-FPM zostały zrestartowane, a Państwo mogą to udowodnić stanem pakietów i czasem startu procesów. Sam numer wersji widoczny w panelu nie wystarcza, ponieważ backporty często zostawiają go bez zmian.
O co chodzi w PHP2Shell na serwerach Plesk
PHP2Shell oznacza dwie krytyczne luki w samym PHP (CVE-2026-109618 i CVE-2026-109619, każda CVSS v4.0 9.2). Pozwalają one atakującym wykonać kod na serwerze bez logowania. Dotyczą między innymi PHP-FPM oraz Apache z mod_php, czyli dokładnie tych trybów pracy, które Plesk konfiguruje dla stron internetowych.
W dniu 21.10.2026 projekt PHP opublikował wersje z usuniętą luką: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji. Serwery Plesk mają pewną osobliwość: często działa na nich obok siebie kilka wersji PHP, część od samego Plesk, część od systemu operacyjnego. Każda z nich wymaga osobnej kontroli.
Aktualizacja w panelu podmienia pliki na dysku. Dopóki w pamięci działają stare procesy PHP, luka pozostaje otwarta. Bez restartu wszystkich procesów roboczych poprawka nie działa.
Aktualizacja PHP w Plesk: najpierw spis zasobów
Zanim cokolwiek Państwo zaktualizują, proszę sporządzić listę wszystkich handlerów PHP i domen, które z nich korzystają. Można to zrobić w panelu (Narzędzia i ustawienia, Ustawienia PHP) lub z wiersza poleceń. Poniższe polecenia niczego nie zmieniają, tylko odczytują.
# Wszystkie zarejestrowane handlery PHP z wersją i ścieżką
plesk bin php_handler --list
# Wersja każdej zainstalowanej przez Plesk wersji PHP (ścieżka jako przykład)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Dla każdego handlera proszę zanotować: wersję, tryb pracy (FPM, FastCGI, moduł Apache) i liczbę domen. Handler bez domeny nie oznacza dania spokoju. Może zostać przypisany później albo działać na subdomenach testowych.
Sprawdzać stan pakietów, a nie wskazanie
Plesk pokazuje numer wersji, który zgłasza samo PHP. Jeśli Plesk lub dystrybucja dostarcza poprawkę jako backport, nadal może tam widnieć na przykład 8.2.34, mimo że korekta jest zawarta. I odwrotnie, pozornie aktualny numer może mylić, jeśli pakiet nie został jeszcze zaktualizowany. Rozstrzygają zainstalowany stan pakietu i pisemne potwierdzenie dostawcy.
# Debian/Ubuntu (nazwy pakietów jako przykład)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (nazwy pakietów jako przykład)
rpm -qa | grep -E 'plesk-php|^php' | sort
Proszę porównać wersje pakietów z informacjami w dziennikach zmian Plesk i w uwagach Państwa dystrybucji. Jeśli nie jest tam jednoznacznie udokumentowane, że CVE-2026-109618 i CVE-2026-109619 zostały usunięte, proszę zapytać dostawcę. Wzór takiego pytania znajdą Państwo w artykule Jak zapytać hostera o stan poprawek.
Instalacja aktualizacji i restart wszystkich procesów roboczych
Właściwa aktualizacja przebiega przez instalator Plesk lub menedżer pakietów systemu. Potem następuje krok, którego najczęściej brakuje: restart. W Plesk każda wersja PHP ma własną usługę FPM. Proszę zrestartować wszystkie, a nie tylko tę dla głównej domeny.
# Wypisz wszystkie usługi PHP-FPM (nazwy usług jako przykład)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Restart każdej usługi, np.:
systemctl restart plesk-php84-fpm
# Sprawdź czas startu działających procesów PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Jeśli domena działa na Apache i mod_php, proszę zrestartować Apache w całości. Jeśli czas startu procesu PHP jest wcześniejszy niż aktualizacja, proces nie został jeszcze odnowiony. Więcej o tym kroku znajdą Państwo w artykule Restart PHP-FPM i wszystkich procesów roboczych.
Ochrona przejściowa, gdy aktualizacji jeszcze brakuje
Jeśli dla danej wersji nie ma jeszcze poprawki, php.net zaleca środki przejściowe. Nie są one pełną ochroną. W Plesk wartości, których aplikacje nie mogą nadpisywać, ustawia się jako php_admin_value w dodatkowych dyrektywach FPM domeny albo ogólnie dla serwera w pliku php.ini danej wersji.
; Przykład dodatkowych dyrektyw PHP-FPM w Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
Przy przesyłaniu plików php.net przewiduje post_max_size = 32M, a upload_max_filesize niższe. W PHP 8.5 dochodzi fatal_error_backtraces=0. Ograniczenie pamięci przez memory_limit=-1 powinno być stosowane wyłącznie razem z limitem na poziomie kontenera lub cgroup. Potem znów następuje restart wszystkich procesów roboczych. Szczegóły podaje artykuł Środki doraźne bez poprawki. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca czasowe odłączenie serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu.
Po poprawce: zabezpieczyć logi i szukać śladów
Poprawka zamyka lukę na przyszłość. Nie usuwa złośliwego oprogramowania wprowadzonego wcześniej i nie dowodzi, że nic się nie stało. Dlatego proszę zachować logi serwera WWW od 20.10.2026. Plesk zapisuje je dla każdej domeny w katalogu logs; w tej sytuacji nie należy skracać czasu ich przechowywania.
Proszę zwrócić uwagę na nowe lub zmienione pliki PHP w katalogach uploadu, nieznane zadania harmonogramu i nowe konta administratorów. Opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dotąd nie ma; wykrywanie opiera się na analizie zachowania. Jeśli znajdą Państwo nieprawidłowości, nie należy działać dalej na własną rękę, tylko najpierw zabezpieczyć stan systemu.
Jak konkretnie pomaga PHP SOS?
- Rejestrujemy wszystkie handlery PHP na Państwa serwerze Plesk, przypisujemy do nich domeny i sprawdzamy rzeczywisty stan pakietów dla każdej wersji.
- W ramach naszej usługi aktualizacji PHP instalujemy aktualizacje, restartujemy wszystkie usługi i dokumentujemy czasy startu procesów jako dowód.
- Tam, gdzie brakuje poprawki, ustawiamy środki przejściowe wg php.net ogólnie dla serwera i w sposób niemożliwy do nadpisania.
- Zabezpieczamy logi i szukamy śladów włamania, a w razie ustaleń wdrażamy reagowanie na incydenty.
- Następnie trwale utwardzamy serwer i usuwamy niepotrzebne wersje PHP.
Częste pytania
Dlaczego Plesk po aktualizacji nadal pokazuje PHP 8.2.34?
Dystrybucje i dostawcy czasem instalują poprawki bezpieczeństwa jako backport, nie zmieniając numeru wersji. Rozstrzygający jest wtedy stan pakietu i potwierdzenie dostawcy. Samo wskazanie w panelu nie dowodzi ani poprawki, ani jej braku.
Czy wystarczy kliknąć w panelu Plesk przycisk Aktualizuj?
Aktualizacja zapisuje nowe pliki, ale działające procesy PHP nadal pracują w pamięci na starym kodzie. Nowy stan jest aktywny dopiero po restarcie wszystkich usług PHP-FPM i serwera WWW. Proszę potem sprawdzić czas startu procesów.
Czy muszę łatać także wersje PHP, z których nie korzysta żadna domena?
Tak, o ile pozostają zainstalowane. Nieużywany handler może zostać później przypadkowo przypisany albo być osiągalny przez środowiska testowe. Niepotrzebne wersje lepiej odinstalować w całości.
Czy aktualizacja WordPressa w Plesk Toolkit pomaga na PHP2Shell?
Nie. PHP2Shell dotyczy samego PHP, a nie CMS. Aktualizacja CMS jest mimo to sensowna, ale tej luki nie zamyka.