PHP2Shell: czy moja strona WordPress jest zagrożona i co zrobić

Każda strona WordPress, która działa na PHP z php.net starszym niż 8.5.12, 8.4.27, 8.3.36 albo 8.2.35, jest podatna na PHP2Shell (pakiety dystrybucji Linuksa mają własne numery, o czym niżej). Te cztery wersje PHP ukazały się 21 października 2026 roku i łatają dwie krytyczne luki, które pozwalają na zdalne wykonanie kodu bez logowania. Luka siedzi w PHP, więc aktualizacja WordPressa, motywu czy wtyczek jej nie usuwa. Trzeba zaktualizować PHP na serwerze albo upewnić się, że zrobił to hosting.

Informacja o każdym z czterech wydań na php.net zawiera to samo zdanie:

Nie ma pełnych środków zaradczych, aktualizacja to jedyny bezpieczny wybór.

(tłumaczenie własne, php.net, informacje o wydaniach z 21 października 2026)

#Czym jest PHP2Shell

PHP2Shell to dwa błędy w silniku PHP, które według strony badaczy odkryły Calif, OpenAI i Wiz. Badania i opis przygotował Ryan Austin z Calif, a błędy znaleziono w ramach inicjatywy Patch the Planet prowadzonej przez OpenAI (Calif). Własną analizę opublikował Wiz Research (Wiz). Projekt PHP prowadzi je jako dwie luki:

Obie to błędy bezpieczeństwa pamięci typu use-after-free w obsłudze błędów krytycznych przez PHP, w tym błędów braku pamięci, a spreparowane żądanie HTTP może je wywołać, zanim wykona się jakikolwiek kod WordPressa. Wpisy w bazie GitHub Security Advisories dla repozytorium php-src opublikowano 21 października 2026 roku o 13:34 UTC. Jako podatne wymieniają wszystkie wersje niższe niż 8.2.35, 8.3.36, 8.4.27 i 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp).

Według osi czasu opublikowanej przez Calif badacze zgłosili pierwszy błąd projektowi PHP 11 sierpnia 2026 roku, PHP potwierdził działanie ich dowodu koncepcji zdalnego wykonania kodu 15 sierpnia, a wydania z poprawkami ukazały się 21 października 2026 roku (Calif).

Dzień wcześniej, 20 października, zespół bezpieczeństwa PHP zapowiedział wydanie na 21 października, godzinę 14:00 UTC, i podał, że obie luki mają ocenę 9.2 w skali CVSS v4.0 (php.net, zapowiedź z 20 października).

Około 16:05 czasu polskiego (14:05 UTC) strona Wordfence pokazywała wyłącznie komunikat: “Usługi Wordfence są chwilowo niedostępne, ponieważ wdrażamy zabezpieczenia przed niezałataną jeszcze luką PHP2Shell. Dziękujemy za cierpliwość” (tłumaczenie własne, strona wordfence.com, stan z 21 października 2026 roku około 16:05). Przy ponownym sprawdzeniu o 17:16 czasu polskiego (15:16 UTC) strona nadal pokazywała tylko ten komunikat. Nawet dostawca zabezpieczeń dla WordPressa wyłączył na ten czas własne usługi, żeby wdrożyć zabezpieczenia.

Z publikacji Wiz Research właściciela strony dotyczą trzy ustalenia:

• podatne są wersje PHP wstecz do 5.4,
• w testach Wiz zdalne wykonanie kodu bez uwierzytelnienia zadziałało na obrazie kontenera wordpress:latest, a także na Drupalu i Joomli,
• osobny błąd pozwala odczytać fragment pamięci procesu PHP, w której mogą być hasła, tokeny uwierzytelniające, klucze API i certyfikaty, nawet gdy aplikacja w ogóle nie uruchamia sesji (session_start()).

Wiz zaznacza też, że poza czterema opisanymi błędami istnieją kolejne warianty tego samego problemu, a poprawka projektu PHP usuwa je wszystkie (Wiz).

#Czy moja strona na WordPressie jest podatna

Tak, jeśli działa na PHP w wersji niższej niż poprawione wydanie z jej gałęzi. Według php.net zagrożona jest każda instalacja PHP obsługująca żądania WWW: PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko php.net przypisuje konfiguracji z mod_php, dla której istnieje pokazany exploit uruchamiany przez niezalogowane żądanie, zanim ruszy kod aplikacji (php.net).

Wersja WordPressa, motywu i wtyczek nie ma tu znaczenia, bo błąd jest w interpreterze PHP, a automatyczne aktualizacje WordPressa nie dotykają PHP na serwerze. Jakość kodu strony też nie chroni: według Wiz nawet prosta aplikacja typu “Hello World” na podatnej wersji PHP może być celem ataku. Wtyczka bezpieczeństwa działa wewnątrz WordPressa, a żądanie może wywołać błąd, zanim WordPress się załaduje.

Sklep WooCommerce ma w tej sytuacji więcej do stracenia niż strona firmowa. W bazie i w konfiguracji leżą dane klientów, zamówienia i klucze do bramek płatności, a ujawnienie pamięci procesu dotyczy właśnie takich sekretów.

Calif potwierdził zdalne wykonanie kodu bez uwierzytelnienia na WordPressie 7.1.2, a także między innymi na Magento 2.4.9, phpMyAdmin 5.2.3 i WHMCS (Calif). W naszej ocenie phpMyAdmin albo panel klienta działający na PHP tego samego serwera jest narażony w ten sam sposób, więc serwer wymaga aktualizacji PHP nawet wtedy, gdy sam WordPress nie jest osiągalny.

Strony statyczne są poza zasięgiem tej luki. Jeśli serwis jest generowany do plików HTML i serwer nie uruchamia PHP przy obsłudze żądań, komunikat php.net go nie dotyczy, bo opisuje instalacje PHP obsługujące żądania WWW.

#Jak sprawdzić wersję PHP na stronie WordPress

Najprostsza droga prowadzi przez kokpit WordPressa:

1. Zaloguj się jako administrator.
2. Otwórz Narzędzia, Stan witryny.
3. Przejdź do zakładki Informacja i rozwiń sekcję Serwer.
4. Odczytaj wiersz z wersją PHP.

Porównaj numer z tabelą:

Daty wsparcia pochodzą z tabeli obsługiwanych wersji na php.net.

Wersja PHP widoczna w Stanie witryny to wersja, która obsługuje stronę WWW. Panel hostingu może pokazywać inną wersję dla wiersza poleceń albo dla innej domeny na tym samym koncie, więc rozstrzyga odczyt z WordPressa.

Wyjątek stanowią pakiety z dystrybucji Linuksa. Według php.net dystrybucje i dostawcy wsparcia LTS dostali poprawki wcześniej i publikują własne pakiety (php.net). Dystrybucja przenosi poprawkę do swojej wersji PHP i zostawia własny numer. Ubuntu 24.04 LTS załatało PHP pakietem 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), więc załatana strona na takim serwerze dalej pokazuje w Stanie witryny 8.3.6. Debian 13 (trixie) dostał php8.4 w wersji 8.4.27-1~deb13u1 (DSA-6574-1), a php8.2 w Debianie 12 (bookworm) tracker bezpieczeństwa Debiana nadal oznaczał jako podatne przy naszym sprawdzeniu 21 października 2026 o 15:14 UTC (Debian security tracker). Na serwerze VPS z PHP z repozytorium dystrybucji sam numer wersji nie rozstrzyga sprawy. Trzeba sprawdzić w komunikacie bezpieczeństwa dystrybucji albo w dzienniku zmian pakietu, czy aktualizacja zawiera poprawki CVE-2026-109618 i CVE-2026-109619, a na hostingu zapytać o to firmę hostingową.

#Co zrobić, jeśli hosting nie zaktualizował jeszcze PHP

Na hostingu współdzielonym aktualizację PHP wykonuje firma hostingowa. Właściciel strony ma cztery ruchy:

1. Zmiana wersji w panelu. Wiele paneli hostingu pozwala wybrać wersję PHP dla domeny. Jeśli na liście jest już wersja z poprawką, przełącz na nią stronę i sprawdź ją w Stanie witryny.
2. Zgłoszenie do hostingu. Napisz do wsparcia technicznego z numerami CVE-2026-109618 i CVE-2026-109619 i zapytaj, kiedy serwer dostanie PHP 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 albo pakiet z tymi poprawkami.
3. Kopia zapasowa przed zmianą. Przejście na nowszą gałąź PHP potrafi wyłączyć starą wtyczkę albo motyw. Kopia plików i bazy sprzed zmiany skraca powrót do działającej strony.
4. Wyłączenie strony do czasu aktualizacji. Jeśli PHP nie da się szybko zaktualizować, wyłącz stronę albo pokaż w jej miejscu statyczną stronę serwisową serwowaną bez PHP. Uwaga od nas: tryb konserwacji z wtyczki WordPressa nie wystarczy, bo żądanie i tak trafia do PHP. John Mueller z Google napisał 21 października: “Jeśli wyłączasz strony w PHP, żeby zyskać czas na nieplanowane aktualizacje, użyj HTTP 503, zamiast pozwalać, by odpowiedzi kończyły się przekroczeniem czasu, 404 albo 500. Możesz to zrobić poza PHP, kierując DNS gdzie indziej albo przez CDN” (tłumaczenie własne, John Mueller, Bluesky). Stronę serwisową z kodem 503 serwuje wtedy serwer WWW, CDN albo inny serwer po zmianie DNS, bez udziału PHP, bo strona konserwacji z kodem 200, przekroczenie czasu, 404 lub 500 mogą zaszkodzić indeksowaniu. Dokumentacja Google Search Central zaleca 503 przy pilnym wyłączeniu strony na 1 do 2 dni, przy dłuższej przerwie indeksowalną stronę główną z kodem 200, i ostrzega przed zwracaniem 503 dla pliku robots.txt (Google Search Central).

WordPress.org napisał 21 października, że luki nie dotyczą wyłącznie WordPressa, a aktualizacja WordPressa nie jest wymagana ani planowana (WordPress.org). Ten sam wpis radzi właścicielom, którzy sami zarządzają serwerem z PHP starszym niż 8.2, rozważyć wyłączenie serwera na czas przygotowania aktualizacji, i przytacza brytyjskie NCSC: gdy nie da się szybko wdrożyć poprawki ani tymczasowych ustawień, NCSC zaleca rozważyć wyłączenie systemu do czasu pełnego zabezpieczenia (NCSC). CERT Polska w komunikacie 195/2026, opublikowanym przed wydaniem poprawki, zalecał “tymczasowe wyłączenie usług wykorzystujących PHP dostępnych z Internetu, o ile nie zakłóci to działalności organizacji” (CERT Polska, 195/2026). Patchstack radzi to samo stronom o wysokim ryzyku i ostrzega przed nieoficjalnymi wtyczkami z “poprawką” oraz kopiowanymi fragmentami kodu, które nie są zweryfikowane i mogą zepsuć stronę (Patchstack). Wtyczka działa wewnątrz PHP, więc błędu w samym PHP nie naprawi.

php.net opisuje tymczasowe ustawienia serwera dla administratorów, którzy nie mogą od razu zaktualizować PHP. Obejmują między innymi limity rozmiaru żądań i wyłączenie śledzenia postępu wysyłania plików w sesji. Te ustawienia działają tylko na poziomie konfiguracji serwera: php.net zastrzega, że dla ustawienia sesji nie wystarczy ini_set() ani plik .user.ini w katalogu strony. Komunikat podkreśla też, że żadne z tych ustawień nie czyni instalacji bezpieczną:

Choć jedynym pełnym rozwiązaniem jest aktualizacja, te środki zmniejszają narażenie na konkretne ścieżki ataku, ale nie czynią instalacji bezpieczną.

(tłumaczenie własne, php.net, komunikat bezpieczeństwa z 21 października 2026)

CERT Polska w komunikacie 196/2026 podaje własne wartości do php.ini i tak samo zastrzega, że nie zastępują one aktualizacji:

Jedyną skuteczną metodą ochrony przed wykorzystaniem podatności jest instalacja poprawnionej wersji PHP. Do tego czasu, aby zminimalizować ryzyko padnięcia ofiarą skutecznego ataku w pierwszej fali masowych prób wykorzystania podatności należy ustawić następujące wartości parametrów PHP w php.ini:

• memory_limit na -1, jeżeli pozwalają na to zasoby, a w przeciwnym wypadku 128M lub więcej,
• post_max_size: 8M lub mniej,
• max_input_vars: 1000 lub mniej,
• session.upload_progress.enabled na Off.

Podkreślamy, że ustawienie tych opcji nie wyklucza możliwości wykorzystania podatności. W pełni zabezpiecza jedynie aktualizacja PHP do bezpiecznej wersji.

(CERT Polska, komunikat 196/2026)

Przy post_max_size php.net dopuszcza 32M dla stron, które przyjmują pliki, a 8M zaleca tam, gdzie wysyłanie plików nie jest potrzebne.

Calif jako tymczasowe i częściowe zabezpieczenie podaje dla PHP-FPM session.upload_progress.enabled=0 razem z memory_limit=-1, a dla mod_php samo memory_limit=-1, i ostrzega, że wartość -1 znosi limit pamięci PHP, co zwiększa ryzyko jej wyczerpania (Calif).

php.net zaleca też usunięcie nieprawidłowych i przestarzałych ustawień PHP stosowanych przy każdym żądaniu, które generują komunikaty przed inicjalizacją, a ukrycie komunikatów przez error_reporting, display_errors albo @ nie pomaga. Przykład od nas, nie z php.net: od PHP 8.3 wszystkie ustawienia assert.* są przestarzałe, więc na PHP 8.3 i nowszym sprawdź .htaccess, pule FPM i php.ini pod kątem pozostałych wpisów assert.*, na przykład php_value assert.active.

Szczegóły tych ustawień dla administratora serwera zebraliśmy w sekcji o krytycznym wydaniu PHP w przewodniku po zabezpieczaniu WordPressa.

Jeśli ruch strony przechodzi przez Cloudflare (pomarańczowa chmurka przy rekordzie DNS), działa dodatkowa warstwa. Według Cloudflare od 21 października 2026 roku, 05:02 czasu polskiego (03:02 UTC), klienci z darmowym lub płatnym WAF są domyślnie chronieni regułami przeciw PHP2Shell, także na planie Free, a na planach Pro, Business i Enterprise trzeba sprawdzić, czy Managed Ruleset działa w trybie blokowania (Cloudflare). Patchstack zastrzega, że te reguły pomagają tylko wtedy, gdy serwer przyjmuje ruch wyłącznie z Cloudflare (Patchstack). Jeśli serwer odpowiada każdemu, żądanie wysłane wprost na jego adres IP omija WAF. Cloudflare podał też, że jeszcze przed oficjalnym wydaniem, gdy informacja o luce wyciekła, obserwował ruch atakujący jego klientów i napastników modyfikujących ładunek ataku, żeby ominąć reguły. Oś czasu Patchstack odnotowuje o 07:34 UTC “wiele incydentów aktywnego wykorzystania zgłoszonych Patchstack przez partnerów hostingowych” (tłumaczenie własne, Patchstack), a Huntress napisał, że do 10:00 czasu wschodnioamerykańskiego (14:00 UTC) nie widział wykorzystania luki wśród swoich partnerów (Huntress). Sam Cloudflare traktuje WAF jako warstwę uzupełniającą i zaleca aktualizację PHP, a ograniczenie wysyłania plików i ich rozmiaru też nie zastępuje poprawki.

#Jak rozpoznać próbę ataku w logach serwera

Wiz zwraca uwagę, że błędy działają poniżej warstwy aplikacji, więc logi WordPressa mogą niewiele pokazać. Do czasu aktualizacji warto szukać w logach serwera trzech sygnałów (Wiz):

• nietypowych żądań typu multipart, po których pojawiają się błędy przekroczenia limitu pamięci albo powtarzające się odpowiedzi HTTP 500,
• nieoczekiwanie dużych albo zniekształconych ciasteczek PHPSESSID w odpowiedziach serwera,
• niewyjaśnionych restartów procesów roboczych PHP.

Te sygnały wskazują, gdzie zacząć sprawdzanie. Ich brak nie oznacza, że ataku nie było, a ich obecność nie zastępuje aktualizacji.

#Czy po aktualizacji trzeba zmienić hasła

Komunikat php.net nie wymaga zmiany haseł. To nasza rekomendacja, oparta na ustaleniu Wiz: luka pozwala odczytać pamięć procesu PHP, w której mogą być hasła, tokeny i klucze API z innych żądań (Wiz). Strona, która przez jakiś czas działała na podatnej wersji, mogła taki sekret ujawnić bez śladu w panelu WordPressa.

Sekrety zmienia się dopiero po aktualizacji PHP, bo nowe hasło ustawione na niezałatanym serwerze może wyciec tą samą drogą co stare.

Co zmienić:

• Klucze i sole w wp-config.php. Nowy zestaw ośmiu stałych generuje oficjalny generator WordPress.org. Po podmianie wszyscy zalogowani użytkownicy zostaną wylogowani.
• Hasło do bazy danych. Zmień je w panelu hostingu i wpisz nowe w wp-config.php jako DB_PASSWORD.
• Hasła kont administratorów i innych kont z uprawnieniami do edycji.
• Klucze API: klucze REST API WooCommerce, klucze bramek płatności, dane logowania SMTP i tokeny usług zewnętrznych zapisane w ustawieniach wtyczek.

#Co z PHP 7.4, 8.0 i 8.1

Projekt PHP nie wydaje już poprawek dla PHP 8.1 i starszych. Komunikat php.net wskazuje dwie drogi: część dystrybucji i dostawców LTS dostarcza poprawki przeniesione wstecz, a pozostali powinni przejść na wspieraną wersję. Ze względu na wagę luk zespół bezpieczeństwa PHP udostępnił minimalne łatki źródłowe dla PHP 7.4, 8.0 i 8.1, przeznaczone dla osób, które kompilują PHP ze źródeł albo nie mają dostępu do dostawcy LTS (php.net).

Dla właściciela strony na hostingu współdzielonym łatki źródłowe nic nie zmieniają, bo PHP na takim serwerze kompiluje i instaluje hosting. Realny wybór to przejście na PHP 8.3, 8.4 albo 8.5 w wersji z poprawką. PHP 8.2 też dostało poprawkę, ale jego wsparcie bezpieczeństwa kończy się 31 grudnia 2026 roku (php.net), więc wybór 8.2 oznacza kolejną zmianę za dwa miesiące.

Tabela zgodności wersji WordPressa i PHP jest w tekście czy warto aktualizować WordPress. Jeśli przejście na nowsze PHP blokuje stary motyw albo wtyczka, plan migracji opisuje przewodnik po modernizacji starszych baz kodu WordPressa. Jeśli sklep WooCommerce po zmianie wersji PHP przestał przyjmować zamówienia albo pokazuje błędy krytyczne, pomoże sprint naprawczy WooCommerce. Przegląd konfiguracji serwera, wersji PHP i kont po incydencie obejmuje audyt bezpieczeństwa WordPress.

#Lista kontrolna dla właściciela strony WordPress i sklepu WooCommerce

Stan na 21 października 2026 roku, około 17:30 UTC, według komunikatu php.net, wpisów GitHub Security Advisories, publikacji Calif i Wiz Research oraz komunikatów Ubuntu, Debiana, WordPress.org, NCSC, CERT Polska, Patchstack i Huntress.