Luka w PHP: łatka PHP2Shell i sprawdzanie wersji PHP (WordPress)

PHP2Shell to nazwa dwóch luk w PHP (CVE-2026-109618 · CVE-2026-109619), na które łatki wydano 21 października 2026 r. To luki zdalnego wykonania kodu, przez które nawet żądanie bez logowania może uruchomić kod na serwerze, dlatego najpierw trzeba sprawdzić, jakiej wersji PHP używa witryna, i zaktualizować ją do wersji z łatką. Na serwerze Nginx + Apache z WordPressem 7.1.3 sprawdzono wersję PHP w Stanie witryny, zaktualizowano tylko pakiety php do wersji z łatką, a potem sprawdzono ją ponownie.

1️⃣ Luka w PHP PHP2Shell: jak działają luki i kogo dotyczą

Luki znajdują się w silniku PHP, który odczytuje żądanie, zanim zostanie wykonany kod WordPressa, więc pozostają nawet przy aktualnych wtyczkach i motywach, dopóki PHP nie zostanie zaktualizowany. Według ostrzeżenia CERT-EU obie mają ocenę CVSS 9,2; szczegóły techniczne są publiczne i omawiane, a w obiegu pojawił się już wstępny kod proof of concept.

CVE-2026-109618 to luka, w której proces porządkowania traktuje zainicjowane tylko w połowie dane żądania jak poprawne, gdy żądanie przekroczy limit pamięci (memory_limit) i zostanie przerwane. CVE-2026-109619 to luka, w której stan pamięci zwolnionej po błędzie krytycznym zostaje i jest ponownie używany przed inicjalizacją przy następnym żądaniu obsługiwanym przez ten sam worker.

Według komunikatu php.net dotyczy to każdej instalacji PHP obsługującej żądania WWW, a za najbardziej niebezpieczną konfigurację uznano Apache mod_php. Na mod_php pokazano bowiem, że jedno żądanie bez logowania uruchamia atak, zanim zostanie wykonany kod aplikacji.

Poprawione wersje to 8.2.35, 8.3.36, 8.4.27 i 8.5.12, a podatne są wszystkie niższe wersje z serii 8.2–8.5. PHP 8.1 i starsze to serie, których projekt PHP już nie wspiera, więc nie ma dla nich oficjalnej wersji z łatką; chronią je poprawki przenoszone przez dystrybucje i firmy hostingowe (backporty).

Gdy CISA opublikowała komunikat 21 października, nie potwierdzono jeszcze faktycznego wykorzystania luk, ale CISA uznała pozostawienie systemów bez łatek za niebezpieczne i zaleciła natychmiastowe łatanie, zaczynając od systemów dostępnych z internetu. CERT-EU w ostrzeżeniu z tego samego dnia uznał, że wraz z pojawieniem się kodu proof of concept wzrosło prawdopodobieństwo, że atakujący już wykorzystują luki.

2️⃣ Sprawdzanie wersji PHP: Stan witryny › Informacja › Serwer

Nawet znając luki, nie wiadomo, co zrobić, dopóki nie wiadomo, na jakiej wersji PHP działa witryna. W panelu administracyjnym należy otworzyć [Narzędzia › Stan witryny] i rozwinąć sekcję [Serwer] na zakładce [Informacja]: wiersz [Wersja PHP] pokazuje wersję PHP, która faktycznie obsługuje żądania witryny.

Wiersz [PHP SAPI] tuż pod [Wersja PHP] pokazuje sposób uruchamiania PHP; fpm-fcgi oznacza konfigurację PHP-FPM. Tutaj wystarczą dwa wiersze sekcji [Serwer]: [Wersja PHP] i [PHP SAPI].

Atak zaczyna się od żądania bez logowania. Na etapie, na którym PHP odczytuje specjalnie spreparowane żądanie przed kodem WordPressa, żądanie uruchamia jedną z dwóch luk, co prowadzi do wykonania kodu na serwerze. Poprawione wersje blokują ten przebieg, więc zadanie polega na podniesieniu PHP witryny co najmniej do poprawionej wersji.

[php -v] w terminalu pokazuje tylko wersję domyślnego PHP wiersza poleceń. W konfiguracjach z kilkoma wersjami PHP na jednym serwerze, takich jak EA-PHP w cPanel czy alt-php w CloudLinux, może się ona różnić od wersji używanej przez witrynę. Dlatego punktem odniesienia jest wartość [Wersja PHP] w Stanie witryny.

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ Poniżej PHP 8.2: sprawdzenie u hostingu, czy wdrożono backport, a jeśli nie, zgłoszenie prośby

Jeśli [Wersja PHP] w Stanie witryny jest niższa niż 8.2 (7.x, 8.0 lub 8.1), nie ma oficjalnej wersji z łatką od php.net. Według tabeli wspieranych wersji na php.net (sprawdzonej 22 października 2026 r.) wspierane są tylko cztery serie: 8.2, 8.3, 8.4 i 8.5, a dla oficjalnych wersji 8.1 i starszych łatki bezpieczeństwa się nie ukazują.

Zamiast tego dystrybucje i firmy hostingowe wydają czasem pakiety, które zachowują numer wersji i przenoszą tylko poprawkę (backporty). Przykładem są pakiety 7.4.33, 8.0.30 i 8.1.34 na serwerze testowym zarządzanego hostingu. W ich dzienniku zmian był wiersz [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619].

Nawet przy tym samym numerze wersji to, czy poprawka jest w pakiecie, sprawdza się, szukając numeru CVE w dzienniku zmian pakietu. W Debianie i Ubuntu szuka się poleceniem w rodzaju [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618]. W systemach RPM ma ono postać [rpm -q --changelog php-common | grep 109618]; numer wersji w nazwie pakietu dopasowuje się do wersji używanej przez witrynę.

Dlatego przy wersji poniżej 8.2 najpierw trzeba zapytać firmę hostingową, czy wdrożono backport, a jeśli nie albo nie da się tego potwierdzić, poprosić o przejście na wspieraną wersję (8.2 lub nowszą). Po aktualizacji należy ponownie sprawdzić wartość [Wersja PHP] w Stanie witryny.

CISA zaleciła organizacjom korzystającym z 8.1 lub starszych wersji, które nie mogą od razu zaktualizować, utrzymywanie systemów opartych na PHP w trybie offline do czasu załatania lub aktualizacji.

Przy samodzielnie prowadzonym serwerze z wersją 8.1 lub starszą można zainstalować pakiety z backportem z dystrybucji albo nałożyć łatki źródłowe dla 7.4, 8.0 i 8.1 wydane przez zespół bezpieczeństwa PHP. To jednak serie bez wsparcia, więc właściwym rozwiązaniem jest przejście na wspieraną wersję.

4️⃣ PHP 8.2 lub nowszy: aktualizacja do wersji z łatką i ponowne sprawdzenie

Przy wersji 8.2 lub nowszej, ale niższej niż wersja z łatką, aktualizuje się samo PHP. W hostingu zarządzanym i współdzielonym łatkę na cały serwer nakłada firma, więc trzeba sprawdzić w jej komunikatach lub przez wsparcie, czy została wdrożona i jaki build działa, a potem zobaczyć, czy [Wersja PHP] w Stanie witryny się zmieniła. Według strony statusu Cloudways zaczął łatać wszystkie wspierane wersje PHP (5.6–8.4) 21 października o 22:19 UTC. 22 października o 10:11 UTC ogłosił zakończenie prac.

Na samodzielnie prowadzonym serwerze aktualizuje się pakietami z repozytorium dystrybucji lub dostawcy LTS, zgodnie z komunikatem php.net. Przed aktualizacją warto w podglądzie sprawdzić listę pakietów, które się zmienią, upewnić się, że aktualizowane są tylko pakiety zaczynające się od php i nie dochodzą żadne inne, oraz nie łączyć tego z innymi aktualizacjami systemu operacyjnego.

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 (pominięto wiersze pakietów rozszerzeń, takich jak php-gd · php-intl)

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  (pominięto wiersze pakietów rozszerzeń)

Complete!

W tym teście do wersji z łatką zaktualizowano tylko pakiety zaczynające się od php, a php-fpm uruchomił się ponownie sam po zakończeniu instalacji pakietów. Poprawiona wersja działa dopiero po ponownym uruchomieniu workerów php-fpm, więc w środowiskach bez automatycznego restartu trzeba samodzielnie wykonać [systemctl restart php-fpm].

Po aktualizacji trzeba sprawdzić, czy zarówno [php -v], jak i wiersz [Wersja PHP] na zakładce [Informacja] w Stanie witryny pokazują wersję z łatką lub nowszą, a także stan usługi php-fpm i odpowiedź witryny. Jeśli zmieniła się tylko wartość w wierszu poleceń, a [Wersja PHP] pozostała bez zmian, należy ponownie uruchomić php-fpm i sprawdzić jeszcze raz.

Także po aktualizacji należy rozwinąć sekcję [Serwer] na zakładce [Informacja] tego samego ekranu [Narzędzia › Stan witryny] i spojrzeć na wiersz [Wersja PHP]. Jeśli ta wartość zmieniła się na zainstalowaną wersję, workery php-fpm też działają już na nowej wersji.

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

200

W pakietach, w których rośnie sam numer wersji, łatkę potwierdza nowy numer wersji, a w pakietach z backportem, które zachowują numer — numer CVE w dzienniku zmian. Ten serwer należał do pierwszej grupy: w [rpm -q --changelog php-common] nie było wiersza z numerem CVE, a łatkę potwierdzono nowym numerem wersji w pierwszym wierszu dziennika zmian.

5️⃣ Gdy nie da się od razu zaktualizować: tymczasowe środki zalecane przez php.net

Dla serwerów, których nie da się od razu zaktualizować, php.net podaje poniższe ustawienia jako środki tymczasowe, zaznaczając, że ograniczają one tylko wybrane ścieżki ataku i nie czynią instalacji bezpieczną. Dodaje też, by nie ustawiać zamiast tego limitu pamięci przez RLIMIT_AS lub RLIMIT_DATA, bo może to wywołać właśnie podatne błędy przydziału pamięci.

php_admin_value to ustawienie po stronie serwera, którego aplikacja nie może cofnąć, dlatego użytkownicy hostingu współdzielonego często nie mogą go zmienić sami i również wtedy muszą zwrócić się do firmy hostingowej. php.net zaleca też ustawienie limitów, także na poziomie serwera WWW lub proxy, dla rozmiaru treści żądania, liczby pól wejściowych, liczby części multipart, liczby nagłówków i głębokości zagnieżdżenia.

🔢 FAQ & polecane treści

🔗 Polecane treści

Bezpieczeństwo Bezpieczeństwo WP: zabezpieczenie wp-admin Ustawienia, które chronią panel administracyjny przez zmianę adresu logowania, ograniczenie prób logowania i blokadę XML-RPC. Czytaj wpis →

Bezpieczeństwo Luki bezpieczeństwa wp-config.php Jak nie dopuścić do ujawnienia pliku wp-config.php i wzmocnić ustawienia bezpieczeństwa. Bezpieczeństwo WordPress XML-RPC Jak rozpoznać ataki na xmlrpc.php w logach i trzy sposoby na jego wyłączenie. Serwer Ostrzeżenie php-fpm max_children Test w praktyce, który znajduje przyczynę ostrzeżenia w logach, zanim doda się workery.

ℹ️ Informacja o linkach partnerskich
Treści tej witryny zawierają linki partnerskie. Jeśli odwiedzający kupi produkt lub usługę przez taki link, witryna otrzymuje od sprzedawcy prowizję. Kwota płacona przy tym przez kupującego ^{(podczas promocji spada↓)} nie wzrasta. Podane ceny, rabaty i dostępność odnoszą się do chwili pisania i mogą różnić się od stanu faktycznego, dlatego przed zakupem sprawdź je u sprzedawcy. Produkty wybieramy i oceniamy według własnych kryteriów, a prowizja nie wpływa ani na kolejność prezentacji, ani na treść ocen.