# Wiele wersji PHP na jednym serwerze: każdą łatać osobno > Wiele wersji PHP na jednym serwerze: znajdź wszystkie instalacje, ustal pochodzenie i odpowiedzialność, załataj każdą osobno, zrestartuj i udokumentuj. Źródło: https://phpsos.de/pl/blog/mehrere-php-versionen-server/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **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. | Źródło | Przykładowa ścieżka | Kto dostarcza poprawkę | |---|---|---| | System operacyjny Debian/Ubuntu | `/usr/bin/php8.3`, `/etc/php/8.3/` | dystrybucja | | System operacyjny z rodziny RHEL | `/usr/bin/php`, `/etc/php-fpm.d/` | dystrybucja | | Plesk | `/opt/plesk/php/8.3/` | Plesk | | cPanel (EasyApache 4) | `/opt/cpanel/ea-php83/` | cPanel | | CloudLinux alt-php | `/opt/alt/php83/` | CloudLinux | | Remi Software Collection | `/opt/remi/php83/` | Remi | | sury.org | `/usr/bin/php8.3` jak w systemie | sury.org | | LiteSpeed | `/usr/local/lsws/lsphp83/` | LiteSpeed lub źródło pakietów | | Skompilowane samodzielnie | często `/usr/local/bin/php` | Państwo sami | | Kontenery | w obrazie | wydawca obrazu, przebudowa przez Państwa | 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](https://phpsos.de/pl/blog/sury-repository-php/) i [Repozytorium Remi](https://phpsos.de/pl/blog/remi-repository-php/). Jak Plesk zarządza swoimi wersjami, opisuje strona [Serwer Plesk: sprawdzanie i łatanie wersji PHP](https://phpsos.de/pl/server/plesk/). ## 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. ```bash # 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](https://phpsos.de/pl/php2shell/php-fpm-neustart/). 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. > **Ważne:** > Proszę nie zapominać o wierszu poleceń. Zadania cron i skrypty często działają z inną wersją PHP niż strona internetowa. Także ta wersja musi mieć poprawiony stan, nawet jeśli nie obsługuje żądań WWW. ## 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](https://phpsos.de/pl/blog/alte-php-versionen-abschalten/). ## 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](https://phpsos.de/pl/leistungen/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 **Dlaczego na moim serwerze działa kilka wersji PHP?** Częste powody to panele hostingowe z własnymi buildami PHP, zewnętrzne źródła, takie jak sury.org lub Remi, dla nowszych wersji oraz starsze aplikacje wymagające konkretnej wersji. Często dochodzi do tego jeszcze wersja PHP systemu operacyjnego. **Czy wersja PHP, z której nie korzysta żadna strona, jest niebezpieczna?** Dopóki jest zainstalowana i aktywna jako usługa, może być osiągalna, na przykład przez domenę testową, zapomnianą pulę lub zadanie cron. Poza tym może zostać później przypadkowo przypisana stronie. Niepotrzebne wersje należy usunąć. **Jak znaleźć wszystkie instalacje PHP na serwerze z Linuxem?** Proszę połączyć trzy perspektywy: zainstalowane pakiety, wykonywalne pliki PHP w systemie plików i działające procesy. Lista jest kompletna dopiero wtedy, gdy wszystkie trzy dają ten sam obraz. **Czy po aktualizacji muszę zrestartować każdą wersję osobno?** Tak. Każda wersja ma zwykle własną usługę FPM, LiteSpeed własne procesy lsphp, a mod_php działa w procesie Apache. Restart usługi głównej nie odnawia pozostałych. ## Źródła - [php.net: komunikaty bezpieczeństwa](https://www.php.net/) - [php.net: wspierane wersje](https://www.php.net/supported-versions.php) - [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)