Wiele wersji PHP na jednym serwerze: każdą łatać osobno

Krótko: Jeśli na serwerze działa kilka wersji PHP, po PHP2Shell każdą trzeba osobno sprawdzić, zaktualizować i zrestartować. Typowe źródła to system operacyjny, panele hostingowe, takie jak Plesk lub cPanel, zewnętrzne źródła, jak sury.org czy Remi, CloudLinux, LiteSpeed oraz wersje skompilowane samodzielnie. Dopiero pełna lista z pakietów, plików i działających procesów pokazuje, czy na pewno żadna wersja nie została pominięta.

Zapomniana wersja

Serwer, który działa od kilku lat, zbiera wersje PHP jak strych stare meble. Panel przyniósł trzy gałęzie, dla jednego klienta doszła starsza wersja z zewnętrznego źródła, system operacyjny ma własną. Każdą z nich kiedyś zainstalowano z dobrego powodu. Tylko że dziś nikt nie wie, która jest jeszcze potrzebna.

Po PHP2Shell właśnie to jest problemem. Poprawki ukazały się 21 października 2026 dla PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Każda instalacja na serwerze otrzymuje je jednak własną drogą, od własnego opiekuna pakietu i we własnym czasie. Dla PHP 8.1 i starszych istnieją tylko minimalne backporty w kodzie źródłowym. Kto zaktualizuje wyłącznie wersję główną, pozostawia pozostałe otwarte.

Skąd biorą się liczne wersje

Poniższe zestawienie wymienia typowe źródła i przykładowe ścieżki. Dokładne ścieżki różnią się w zależności od wersji i dystrybucji.

Szczególnie podstępne są pakiety sury.org, ponieważ używają tych samych ścieżek co dystrybucja. To, czy php8.3 pochodzi z Debiana, czy z sury.org, pokazuje dopiero źródło pakietu. Szczególne cechy opisują artykuły Repozytorium sury.org i Repozytorium Remi. Jak Plesk zarządza swoimi wersjami, opisuje strona Serwer Plesk: sprawdzanie i łatanie wersji PHP.

Znalezienie wszystkich instalacji PHP

Wiarygodna lista powstaje z trzech perspektyw. Polecenia tylko odczytują dane i mogą na niektórych serwerach działać dłuższy czas.

# 1. Pakiety: co zna zarządzanie pakietami
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Pliki: wykonywalne binaria PHP, także poza zarządzaniem pakietami
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Procesy: co faktycznie działa w tej chwili, z czasem startu
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Proszę porównać trzy listy. Plik bez pakietu wskazuje na wersję skompilowaną samodzielnie lub skopiowaną ręcznie. Proces bez pasującego pliku może wskazywać na usuniętą, ale wciąż działającą instalację. W Apache proszę dodatkowo sprawdzić, czy załadowany jest moduł PHP, na przykład poleceniem apache2ctl -M lub httpd -M. Kontenery i pody Kubernetes pojawiają się na tych listach tylko częściowo i wymagają osobnej kontroli obrazów.

Łatanie każdej wersji osobno

Gdy każda instalacja ma wiersz na Państwa liście, dla każdej następuje ten sam przebieg:

1. Wyjaśnić odpowiedzialność: Czy poprawka pochodzi od dystrybucji, od panelu, ze źródła zewnętrznego, czy od Państwa samych?
2. Ocenić stan: oficjalna poprawiona wersja, potwierdzony backport, niewyjaśnione lub otwarte.
3. Zaktualizować: drogą danego źródła, a nie inną.
4. Zrestartować: usługę tej wersji, a nie tylko usługę główną. W przypadku mod_php serwer WWW. Szczegóły znajdą Państwo w Restart PHP-FPM i wszystkich workerów.
5. Skontrolować: porównać czas startu procesów z momentem aktualizacji.
6. Udokumentować: wersja, stan pakietu, dowód, czas restartu.

Dla wersji, dla których nie ma poprawki, do czasu migracji obowiązują środki przejściowe z php.net. Proszę je ustawić osobno dla każdej wersji, ponieważ każda instalacja ma własny php.ini i własne pule.

Której wersji używa wiersz poleceń, a której kontener?

Dwa obszary szczególnie często wypadają z siatki poszukiwań. Pierwszy to wiersz poleceń. W Debianie i Ubuntu system alternatyw decyduje, które binarium kryje się za poleceniem php. update-alternatives --display php pokazuje, które wersje są zarejestrowane i która obowiązuje. Zadania cron wywołujące stałą ścieżkę, jak /usr/bin/php7.4, omijają jednak to ustawienie. Dlatego warto zajrzeć do crontabów wszystkich użytkowników i do konfiguracji paneli, które same zakładają zadania cron.

Drugi obszar to kontenery. Kontener Docker na serwerze ma własną wersję PHP, która nie pojawia się na żadnej liście pakietów hosta. docker ps pokazuje działające kontenery; czy jest w nich PHP i w jakiej wersji, ujawnia spojrzenie na obraz lub php -v w kontenerze. Poprawka następuje tam nie na hoście, lecz przez przebudowę obrazu i wymianę kontenera.

Mniej znaczy bezpieczniej

Najlepsza kontrola to ta, której nie trzeba wykonywać. Każda zainstalowana wersja PHP podwaja nakład pracy przy następnej luce. Po PHP2Shell opłaca się więc jasna zasada: każda wersja na serwerze potrzebuje celu i osoby odpowiedzialnej. Wersja, która nie ma żadnego z nich, jest najpierw dezaktywowana, a po okresie obserwacji usuwana. Więcej w artykule Wyłączanie starych wersji PHP w panelu hostingowym.

Jak konkretnie pomaga PHP SOS?

• Sporządzamy dla Państwa serwerów pełną listę wszystkich instalacji PHP z pakietów, plików, procesów i kontenerów.
• Dla każdej wersji wyjaśniamy pochodzenie, odpowiedzialność i stan poprawek.
• W ramach usługi PHP-Patch-Service aktualizujemy każdą wersję, restartujemy każdą usługę i dokumentujemy stan.
• Wspólnie z Państwem ustalamy, które wersje zostają, i w sposób kontrolowany usuwamy pozostałe.

Częste pytania

Źródła

• php.net: komunikaty bezpieczeństwa
• php.net: wspierane wersje
• Red Hat Security Bulletin RHSB-2026-013