Krótko: Aby sprawdzić wersję PHP, nie wystarcza php -v. Muszą Państwo wiedzieć, której wersji PHP faktycznie używa serwer WWW, czy pakiet zawiera poprawkę, także jako backport ze starym numerem, oraz czy po aktualizacji zrestartowano wszystkie procesy. PHP2Shell jest naprawione w 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Dlaczego sam numer wersji nie wystarcza
Dla PHP2Shell istnieje jasna lista naprawionych wersji. W praktyce do błędnych ocen prowadzą jednak trzy sytuacje:
- Kilka instalacji: Wiersz poleceń pokazuje PHP 8.3, ale strona działa przez pulę z PHP 8.1.
- Backporty: Dystrybucje i dostawcy hostingu wprowadzają poprawki częściowo do istniejących pakietów. Wtedy na przykład Plesk nadal pokazuje 8.2.34, mimo że jest załatane.
- Stare procesy: Nowe pliki leżą na dysku, ale działające workery pochodzą jeszcze sprzed aktualizacji.
Dla zarządu i osób nietechnicznych pomaga prosta zasada: nie pytać tylko „Jaką wersję PHP mamy?”, lecz „Czy PHP2Shell jest zamknięte na wszystkich serwerach i po czym to widzimy?”. Wiarygodna odpowiedź zawiera trzy dowody: wersję lub backport, stan pakietów i czas restartu.
Kontrola techniczna ma więc trzy kroki: wersja, stan pakietów, działające procesy. Poniższe polecenia służą wyłącznie do odczytu. Nazwy pakietów i usług różnią się zależnie od dystrybucji, źródła PHP i interfejsu hostingu; przykłady zakładają PHP 8.3.
Sprawdzanie wersji PHP w wierszu poleceń
php -v # wersja wiersza poleceń
ls /etc/php/ 2>/dev/null # Debian/Ubuntu: zainstalowane gałęzie
php-fpm8.3 -v # wersja binarki FPM (nazwa zależy od dystrybucji)
php -i | grep -E "^PHP Version|Server API|Loaded Configuration File"
W RHEL, AlmaLinux lub Rocky binarka FPM nazywa się zwykle php-fpm; przy Software Collections lub źródłach zewnętrznych dalsze wersje leżą we własnych ścieżkach. Plesk i cPanel mają własne instalacje PHP, istniejące obok PHP systemowego. Jak postępować w ich przypadku, opisujemy na stronach o Plesk i cPanel.
Którą wersję PHP strona używa w kontekście WWW, najpewniej widać w konfiguracji puli lub VirtualHost albo w interfejsie hostingu. Pokazuje to także strona phpinfo; proszę utworzyć ją tylko na krótko, z ochroną dostępu i losową nazwą, i od razu potem usunąć.
Na hostingu współdzielonym zwykle nie mają Państwo dostępu do wiersza poleceń. Wtedy interfejs hostingu pokazuje ustawioną wersję PHP dla każdej strony. Czy backport został wprowadzony i zrestartowany, rzadko tam widać. Wiarygodną drogą jest tu pisemne potwierdzenie dostawcy hostingu.
Sprawdzanie stanu pakietów i backportów
Stan pakietów pokazuje, co Państwa dystrybucja faktycznie dostarczyła:
# Debian/Ubuntu
apt policy php8.3-fpm
apt changelog php8.3-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"
# RHEL, AlmaLinux, Rocky, Fedora
dnf info php-fpm
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"
Jeśli w changelogu stoi jeden z numerów CVE, backport jest zawarty w zainstalowanym pakiecie. Jeśli wpisu brakuje, nie jest to jeszcze dowód luki: niektórzy opiekunowie pakietów formułują changelogi inaczej. Wtedy proszę porównać wersję pakietu z komunikatami bezpieczeństwa Państwa dystrybucji lub zapytać dostawcę. Wzór takiego zapytania znajdą Państwo na stronie Jak zapytać dostawcę hostingu o stan poprawek.
Ważne: proszę sprawdzić każdy zainstalowany pakiet PHP, a nie tylko pierwszy. Na serwerach z kilkoma gałęziami często jedna jest załatana, a inna nie.
Czy nowa wersja rzeczywiście działa?
Aktualizacja działa dopiero wtedy, gdy wszystkie procesy PHP zostały zrestartowane. Proszę porównać czas uruchomienia działających procesów z momentem aktualizacji:
ps -o pid,lstart,cmd -C php-fpm8.3 # czas startu procesów FPM
systemctl status php8.3-fpm # od kiedy usługa działa
needrestart -r l # Debian/Ubuntu, jeśli zainstalowano: pokazuje przestarzałe procesy
Jeśli czas uruchomienia jest sprzed aktualizacji, nadal działają stare procesy. Przy Apache z mod_php to samo dotyczy procesów Apache. Jak prawidłowo zrestartować, opisuje strona Restart PHP-FPM i wszystkich workerów.
Proszę zapisać wynik na piśmie: serwer, wersja PHP, wersja pakietu, CVE w changelogu tak lub nie, czas restartu. Ta notatka będzie potrzebna dla zarządu, ubezpieczyciela i późniejszej kontroli śladów.
Ocena wyniku
| Ustalenie | Ocena |
|---|---|
| Oficjalna wersja 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, procesy zrestartowane | PHP2Shell zamknięte |
| Starszy numer, numery CVE w changelogu pakietu, procesy zrestartowane | backport wprowadzony, zamknięte |
| Starszy numer, brak wpisu w changelogu, brak potwierdzenia | niejasne, wyjaśnić u dostawcy |
| PHP 8.1 lub starsze bez potwierdzonego backportu | otwarte, potrzebne środki przejściowe i migracja |
| Procesy starsze niż aktualizacja | brak restartu, luka nadal aktywna |
Jeśli serwer pozostaje w statusie „niejasne”, proszę traktować go jak otwarty: ustawić środki przejściowe i dopilnować wyjaśnienia, aż pojawi się dowód. Pełne zestawienie wersji znajdą Państwo na stronie Które wersje PHP są podatne?.
Jak konkretnie pomaga PHP SOS?
Dzięki usłudze łatania PHP przejmujemy sprawdzenie i dowód:
- Znalezienie wszystkich instalacji, także drugich wersji z paneli hostingowych, Software Collections lub kontenerów.
- Ocena stanu pakietów: oficjalne wydanie, backport lub otwarte, z dowodem z changelogu albo od dostawcy.
- Kontrola restartu, aż żaden proces ze starym kodem już nie działa.
- Sporządzenie protokołu kontroli, który mogą Państwo wykorzystać wewnętrznie i wobec osób trzecich.
Częste pytania
Dlaczego php -v pokazuje inną wersję niż moja strona?
Na wielu serwerach zainstalowanych jest kilka wersji PHP. Wiersz poleceń używa jednej z nich, serwer WWW lub pula FPM innej. Proszę więc sprawdzić wersję, która faktycznie działa w kontekście WWW, na przykład przez binarkę FPM lub interfejs hostingu.
Jak rozpoznać backport?
W pakietach dystrybucji poprawka znajduje się często w changelogu pakietu, zwykle z numerem CVE. W Debianie i Ubuntu pomaga apt changelog, w systemach typu RHEL rpm -q --changelog. Jeśli wpisu brakuje, stan trzeba wyjaśnić u dostawcy.
Czy mogę sprawdzić wersję PHP w menu klienta hostingu?
Tak, większość interfejsów pokazuje ustawioną wersję dla każdej strony. Czy backport został wprowadzony i zrestartowany, zwykle tam nie widać. Wiarygodną drogą jest do tego pisemne potwierdzenie dostawcy hostingu.