21 października zespół PHP wydał poprawki dwóch krytycznych luk, nazwanych PHP2Shell. Problem leży w PHP, czyli w języku, w którym na serwerze działa cała strona razem z WordPressem, wtyczkami i motywem. Dlatego kliknięcie „Aktualizuj” w kokpicie niczego tu nie zmienia, a poprawkę musi zainstalować ten, kto zarządza serwerem.
Poniżej opisuję, jak w 2 minuty sprawdzić, na jakiej wersji PHP stoi Twoja strona, jak odczytać ten numer i o co dokładnie zapytać hosting, gdy wersja jest stara.
- Bezpieczne wersje PHP to 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz nowsze. Na niższym numerze z tych gałęzi strona jest podatna.
- Aktualizacja WordPressa, wtyczek i motywu nie usuwa PHP2Shell. Łatkę instaluje hosting albo administrator serwera.
- Dla PHP 8.1 i starszych oficjalnej poprawki nie ma. Część dostawców przeniosła ją do swoich pakietów, więc sam numer wersji nie powie Ci, czy serwer jest załatany. Rozstrzyga odpowiedź hostingu.
- Reguły zapory Cloudflare są tylko łatą na kilka dni. Chronią wyłącznie wtedy, gdy serwer przyjmuje ruch tylko z Cloudflare.
Co się stało 21 października
PHP wydał poprawki dwóch luk oznaczonych CVE-2026-109618 i CVE-2026-109619. Obie dostały ocenę 9,2 w 10-stopniowej skali CVSS, czyli najwyższą kategorię, „krytyczna”. Luki siedzą w samym interpreterze PHP, więc zagrożona jest każda strona na podatnej wersji, niezależnie od tego, czy to WordPress, sklep WooCommerce czy własny skrypt.
Według zestawienia firmy Patchstack, która zajmuje się bezpieczeństwem WordPressa, problem dotyczy wszystkich sposobów uruchamiania PHP na serwerach WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Badacze z Wiz Research pokazali zdalne uruchomienie własnego kodu, czyli przejęcie strony, na najnowszym obrazie kontenera WordPressa, a także odczyt pamięci procesów PHP, w której bywają hasła, tokeny i klucze dostępowe do zewnętrznych usług.
Pierwsze sygnały o atakach hostingodawcy zgłosili Patchstack jeszcze rano 21 października, zanim poprawki wyszły. Po południu tego samego dnia dane z monitoringu pokazywały głównie skanowanie, czyli roboty sprawdzające, które serwery są podatne. Tak zwykle wygląda pierwsza doba po publikacji groźnej luki. Najpierw ktoś robi listę celów, a potem wraca z właściwym atakiem.
Dlaczego aktualizacja WordPressa tym razem nie pomoże
WordPress jest programem napisanym w PHP, a PHP jest silnikiem zainstalowanym na serwerze, który ten program wykonuje. Kokpit WordPressa aktualizuje tylko to, co leży w katalogu strony: rdzeń, wtyczki i motyw. Do silnika nie ma dostępu, tak samo jak lokator nie wymieni instalacji gazowej w całym bloku, choć może odnowić własną kuchnię.
To ważne, bo wielu właścicieli stron, z którymi rozmawiamy, utożsamia bezpieczeństwo z zielonymi znaczkami przy wtyczkach. Przy PHP2Shell strona może mieć wszystko aktualne i nadal być otwarta. W ramach stałej opieki technicznej nad WordPressem wersję PHP sprawdzamy razem z wersjami wtyczek, bo to dwie różne warstwy i każdą łata kto inny.
Dla porównania, przy niedawnej luce w samym WordPressie do wersji 7.1.1 wystarczyła aktualizacja rdzenia i wielu stronom zrobiła się sama. Przy PHP2Shell automatyczne aktualizacje WordPressa w ogóle nie dotykają problemu.
Jak sprawdzić wersję PHP w Zdrowiu witryny
Wersję PHP odczytasz w kokpicie WordPressa bez logowania do hostingu. Wejdź w Narzędzia > Zdrowie witryny, przejdź na zakładkę Informacje, rozwiń sekcję Serwer i znajdź wiersz Wersja PHP. Potrzebujesz konta administratora.

Sam numer trzeba jeszcze dobrze odczytać. Na nowych gałęziach PHP sprawa jest prosta, bo poprawka dostała konkretny numer wydania. Na gałęziach 8.1 i starszych projekt PHP nie wydaje już żadnych aktualizacji, więc poprawkę przenoszą do swoich pakietów dystrybucje Linuksa i część dostawców hostingu. Taki serwer zwykle pokazuje stary numer główny, na przykład 8.1.2, mimo że łatka jest w środku.
| Wersja w Zdrowiu witryny | Co to znaczy | Co zrobić |
|---|---|---|
| 8.2.35, 8.3.36, 8.4.27, 8.5.12 lub wyższa w tej gałęzi | Poprawka jest | Nic, sprawdź za tydzień ponownie |
| 8.2, 8.3, 8.4 lub 8.5 z niższym numerem | Serwer czeka na łatkę | Napisz do hostingu dziś |
| 8.1, 8.0, 7.4 i starsze | Numer nie rozstrzyga | Zapytaj hosting o poprawkę i plan przejścia na nowsze PHP |
Ostatni wiersz jest najważniejszy. Według zestawienia Patchstack poprawki dla starych gałęzi istnieją między innymi w pakietach Ubuntu 22.04 i w repozytorium Remi dla 7.4, 8.0 i 8.1, ale już nie dla 7.2 i 7.3. Oficjalny obraz Dockera z PHP 8.1 i starszym poprawki nie dostał wcale. Na hostingu współdzielonym nie widzisz, z czego dostawca buduje PHP, więc jedyną pewną odpowiedź daje jego obsługa.
Co zrobić, gdy strona stoi na PHP 8.1 albo starszym
Napisz do hostingu jeszcze dziś i zadaj 2 konkretne pytania. Ogólne „czy jesteśmy bezpieczni” zwykle kończy się ogólną odpowiedzią, a Tobie potrzebna jest data i nazwa poprawki.
- Czy PHP, na którym działa moja strona, ma już poprawki CVE-2026-109618 i CVE-2026-109619 (PHP2Shell), a jeśli tak, to od kiedy?
- Czy mogę od razu przełączyć stronę na PHP 8.2 lub nowsze i gdzie to zrobię w panelu?
Drugie pytanie jest ważniejsze, niż wygląda. PHP 8.1 i starsze nie dostają już oficjalnych poprawek, więc przy następnej luce sytuacja się powtórzy. Wiele paneli hostingowych pozwala zmienić wersję PHP jednym kliknięciem, tyle że stara strona po takim przełączeniu potrafi pokazać biały ekran albo błąd krytyczny. Kolejność bezpiecznej zmiany, od kopii zapasowej po test na kopii strony, opisaliśmy w poradniku jak zaktualizować PHP w WordPressie.
Gdy strona ma kilka lat i wtyczki, których nikt od dawna nie ruszał, przejście z PHP 7.4 na 8.2 rzadko kończy się na jednym kliknięciu. U klientów najczęściej blokują je porzucone wtyczki i stare motywy pisane pod dawne PHP. Sam WordPress rzadko sprawia tu kłopot. Lepiej poznać tę listę przed przełączeniem niż po nim, na działającej stronie.
Czy Cloudflare wystarczy na czas oczekiwania na hosting
Cloudflare udostępnił wstępne reguły zapory dla wszystkich swoich klientów, także na darmowym planie, i sam nazywa je rozwiązaniem tymczasowym. To dobra wiadomość, jeśli Twoja domena już przez Cloudflare przechodzi. Reguły działają jednak tylko wtedy, gdy serwer przyjmuje ruch wyłącznie z Cloudflare.
Na małych stronach ten warunek zwykle nie jest spełniony. Adres IP serwera da się znaleźć w starych rekordach DNS, w nagłówkach maili wysyłanych ze strony albo w historii domeny, a atakujący, który go zna, omija zaporę i trafia prosto w PHP. Traktuj więc Cloudflare jak taśmę na pękniętą rurę. Pomaga przetrwać kilka dni, ale nie zastępuje hydraulika.
Jedynym pełnym rozwiązaniem jest PHP z poprawką. Jeśli nie chcesz pilnować takich komunikatów sam, sprawdź cennik opieki WordPress. W każdym planie wersję PHP i stan łatek kontrolujemy za Ciebie, a z hostingiem rozmawiamy, zanim zrobi się nerwowo.
Pytania i odpowiedzi
Czy luka PHP2Shell dotyczy mojej strony na WordPressie?
Tak, jeśli serwer działa na podatnej wersji PHP. Luka siedzi w PHP, a nie w WordPressie, więc znaczenie ma wyłącznie wersja PHP i to, czy hosting wgrał poprawkę. Wersję sprawdzisz w Narzędzia > Zdrowie witryny > Informacje > Serwer.
Które wersje PHP są bezpieczne po PHP2Shell?
Poprawione wersje to 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz nowsze w tych gałęziach. Dla PHP 8.1 i starszych projekt PHP nie wydał poprawki, a bezpieczeństwo zależy od tego, czy dostawca serwera przeniósł ją do swojego pakietu.
Czy mogę sam zaktualizować PHP?
Na większości hostingów współdzielonych możesz zmienić wersję PHP w panelu, ale nie zainstalujesz sam poprawki w danej wersji, bo to robi dostawca. Przed zmianą wersji zrób kopię zapasową i sprawdź stronę na kopii testowej, bo stare wtyczki mogą nie działać na nowszym PHP.
Czy wtyczka bezpieczeństwa ochroni stronę przed PHP2Shell?
Nie można na tym polegać. Wtyczka działa wewnątrz WordPressa, czyli już po tym, jak serwer przekazał zapytanie do PHP, a luka dotyczy samego PHP. Ochronę daje dopiero PHP z poprawką, a reguły zapory Cloudflare tylko na krótko i tylko wtedy, gdy serwer przyjmuje ruch wyłącznie przez Cloudflare.
