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żam zabezpieczenia przed niezałataną jeszcze luką PHP2Shell. Dziękuję 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.

Fińskie rządowe centrum ICT Valtori zaczęło zapobiegawczo wyłączać publiczne serwisy administracji centralnej 21 października tuż po 13:00 czasu fińskiego, a strona fińskiego urzędu geodezyjnego Maanmittauslaitos nie działała już o 15:11 (Yle News). Uniwersytet we Fryburgu ogłosił o 10:39 czasu lokalnego, że jego strony i kluczowe usługi zostaną wyłączone (centrum obliczeniowe Uniwersytetu we Fryburgu).

W Holandii NOS podał o 11:10 czasu polskiego, że swoje strony wyłączyły Tweede Kamer, NCSC, Autoriteit Persoonsgegevens i serwis Tweakers, a NotuBiz, system do obsługi posiedzeń rad, z którego korzysta około stu gmin, przestał działać już rano (NOS). Czasowo niedostępne były też strona Uniwersytetu Wiedeńskiego i wiki explain xkcd (ORF, explain xkcd). Według W3Techs PHP działa na 69,3% stron, których język po stronie serwera serwis rozpoznaje (stan na 23 października 2026). Dlatego jeden błąd w interpreterze zmusił naraz tyle organizacji do wyłączenia stron (W3Techs).

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). Automattic napisał 21 października 2026 roku, że strony na WordPress.com, WordPress VIP, WP Cloud, Pressable i Tumblr są już chronione, a ich właściciele nie muszą nic robić (Automattic), więc aktualizacja dotyczy stron, na których PHP utrzymuje sam właściciel albo inny hosting.

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 mojej 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). Jeśli korzystasz z prowadzonego przez wolontariuszy repozytorium rpms.remirepo.net, php.net wzywa do przejścia na pakiety dystrybucji albo kompilacji ze źródeł, żeby móc od razu instalować aktualizacje, i uprzedził, że w dniu wydania repozytorium nie dostanie aktualizacji (php.net, 21 października 2026). 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 moim 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. Moja uwaga: 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ślam, ż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).

Advisories projektu PHP przypisują środki doraźne do konkretnych luk. Dla CVE-2026-109618 podstawowym zabezpieczeniem w konfiguracji jest ustawienie i wymuszenie memory_limit=-1. Advisory zaznacza, że nie jest ono pełne, bo nieudana alokacja pamięci nadal może poprowadzić PHP podatną ścieżką, i odradza RLIMIT_AS oraz RLIMIT_DATA, które właśnie tę ścieżkę wywołują. Zaleca też ostrożny post_max_size egzekwowany dodatkowo na serwerze stojącym przed PHP, limity liczby części, nagłówków i przesyłanych plików oraz blokowanie tam żądań multipart, jeśli aplikacja ich nie używa. Po poprawce PHP zgłasza miękki błąd braku pamięci w bezpiecznym punkcie, a proces kończy dopiero po przekroczeniu drugiego, wyższego progu (GHSA-w8hw-w9fx-j79w). Ustawienie session.upload_progress.enabled=0 pochodzi z advisory dla CVE-2026-109619 i według niego zamyka tylko pokazaną tam ścieżkę w cyklu życia sesji, a pozostałych ścieżek nie obejmuje (GHSA-6wmf-4rv5-p3rp). Moja uwaga: WordPress przesyła w ten sposób pliki do biblioteki mediów i dane wielu formularzy, więc całkowita blokada żądań multipart psuje panel i formularze. Ta opcja pasuje tylko do stron, które nie przyjmują plików.

Dla CVE-2026-109619 na PHP 8.5 php.net podaje też ustawienie fatal_error_backtraces=0 i restart wszystkich procesów roboczych, a według komunikatu zamyka to tylko potwierdzoną ścieżkę przez ślad stosu przy błędzie krytycznym (php.net, 21 października 2026). Ten sam komunikat zaleca 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 ode mnie, 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.

Aktualizacja, 24 października 2026. Wydania z 21 października nie zamykają wszystkich ścieżek. 23 października php.net opublikował komunikat informacyjny o kolejnym wektorze zdalnego wykonania kodu, CVE-2026-115560. Projekt PHP uznaje go za mało prawdopodobny w praktyce, naprawi go w najbliższym zwykłym wydaniu poprawkowym i dopiero wtedy opublikuje pełny komunikat. Dotyczy więc także serwerów już zaktualizowanych, ale wymaga trzech warunków naraz: konfiguracja ustawia session.serialize_handler na php_binary albo php_serialize, aplikacja w trakcie działania przełącza go na php przez ini_set() przed wywołaniem session_start(), a śledzenie postępu wysyłania plików w sesji jest nadal włączone. Aplikacje, które nigdy nie zmieniają serializatora w trakcie działania, mogą zostawić tę funkcję włączoną. Do tego wydania php.net sugeruje session.upload_progress.enabled=0. Jeśli ustawiłeś to już 21 października jako zabezpieczenie przed CVE-2026-109619, zostaw je i nic więcej nie musisz robić (php.net, 23 października 2026). Jak je wprowadzić, opisuje komunikat z 21 października: w php.ini, w puli FPM albo w konfiguracji serwera, nie przez ini_set() ani .user.ini, a potem restart wszystkich procesów roboczych. Na hostingu współdzielonym oznacza to prośbę do firmy hostingowej. Moja uwaga: żeby sprawdzić, czy jakiś kod na twoim serwerze przełącza serializator, przeszukaj wtyczki, motywy i własny kod pod kątem session.serialize_handler, na przykład poleceniem grep -rn "session.serialize_handler" wp-content/.

Szczegóły tych ustawień dla administratora serwera zebrałem 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.

Aktualizacja, 23 października 2026. Dzień po wydaniu poprawek Wordfence napisał, że w ponad pięciu milionach chronionych przez siebie witryn WordPress nie zaobserwował żadnego potwierdzonego włamania przez te dwie podatności, a jego zapora zatrzymała w tym czasie ponad 74 000 prób ataku i sondowania. W próbce żądań z okresu od 20 do 22 października, której Wordfence nie uważa za reprezentatywną dla całego ruchu, żądania próbują odczytać .env i wp-config.php, uruchomić polecenia takie jak id i uname -a oraz zapisać powłokę PHP o nazwie wp2s.php w zapisywalnych folderach na przesłane pliki, wtyczki lub motywy. Pokazują zamiar, nie udany atak. Wordfence dodaje, że brak potwierdzonego włamania w jego danych nie oznacza, że serwer bez aktualizacji jest bezpieczny, bo część awarii zachodzi poza WordPressem i jego logami (Wordfence, 22 października 2026). Na serwerach z Debianem i Ubuntu, które instalują PHP z repozytorium deb.sury.org, pakiety przygotowuje Ondřej Surý, deweloper Debiana, na którego pracy opierają się oficjalne pakiety PHP w Debianie i Ubuntu. Sam pisze, że robi to głównie w wolnym czasie (deb.sury.org). Gdy sprawdzałem 23 października, jego repozytorium dla Debiana 12 miało już wersje 8.2.35, 8.3.36, 8.4.27 i 8.5.12 zbudowane 21 października (packages.sury.org). Dotyczy to każdej aplikacji w PHP, także sklepu, CRM-a czy innego CMS-a: sprawdź, kto buduje pakiety PHP na twoim serwerze i czy twoja gałąź nadal dostaje poprawki, porównaj zainstalowaną wersję z wersją naprawioną i po aktualizacji zrestartuj wszystkie procesy PHP. Pilnowanie tego na serwerach klientów to część mojej opieki nad stronami WordPress.

#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.

Aktualizacja, 28 października 2026. Tydzień po poprawkach Wordfence nadal nie zna żadnej strony na WordPressie przejętej przez PHP2Shell, a jego zespoły od czyszczenia stron nie obsłużyły takiego przypadku. Próby trwają: osobna reguła monitorująca zapisała od 23 do 27 października około 77 600 powiązanych żądań z ponad 2000 adresów IP i żadne z nich nie wyglądało na zwykły ruch odwiedzających. Narzędzia napisane pod te luki pojawiły się w danych Wordfence 21 października, mniej więcej cztery godziny przed publicznym ogłoszeniem. W laboratorium Wordfence testowy exploit wykonał kod na specjalnie skonfigurowanej kompilacji PHP, a na zwykłej, zoptymalizowanej kompilacji tej samej wersji tylko wywrócił proces. Exploit trzeba więc dopasować do konkretnego serwera, co spowalnia masowe ataki, ale niczego nie naprawia (Wordfence, 28 października 2026). Na własnym serwerze sprawdzisz dwie rzeczy. Polecenie find wp-content -name "*.php" -newermt 2026-10-17 wypisze pliki PHP utworzone lub zmienione od 17 października, a w wp-content/uploads nie powinno być żadnego. cat /proc/sys/kernel/randomize_va_space powinno zwrócić 2, czyli pełną losowość układu pamięci (ASLR). Logi serwera, PHP i zapory zachowaj od 17 października do dnia, w którym PHP po aktualizacji zostało zrestartowane. Jeśli znajdziesz obcy plik albo nieznane konto administratora, traktuj stronę jako przejętą: najpierw kopia w obecnym stanie jako dowód, potem nowe hasło do bazy i nowe klucze z wp-config.php. Jeśli naruszenie dotknęło danych osobowych, art. 33 RODO daje 72 godziny na zgłoszenie do UODO. Tak prowadzę usuwanie wirusów i naprawę po włamaniu.

#Czy po aktualizacji trzeba zmienić hasła

Komunikat php.net nie wymaga zmiany haseł. To moja 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.

Aktualizacja, 27 października 2026. Przy przejściu na nowszą gałąź PHP jedna awaria wygląda wyjątkowo dziwnie: zamiast strony przeglądarka pobiera plik, zwykle index.php. Serwer przestał wtedy przekazywać pliki .php do interpretera i wysyła je jak zwykłe pliki. Na Apache przyczyną bywa linia AddHandler w .htaccess, która przypisuje rozszerzenie .php do handlera wersji PHP usuniętej z serwera (Apache, mod_mime). Diagnozę potwierdzisz jednym poleceniem: curl -sI https://example.com/ pokaże Content-Type: application/octet-stream zamiast text/html. Naprawa to wybór wspieranej wersji w panelu hostingu i usunięcie starej linii AddHandler, a nie przywracanie kopii zapasowej. Moja uwaga, której zwykle brakuje w poradnikach: dopóki PHP nie działa, każdy plik .php da się pobrać w postaci źródłowej, także wp-config.php z hasłem do bazy danych i kluczami. Jeśli awaria trwała dłużej niż chwilę, po naprawie sprawdź w logu dostępu, czy ktoś pobrał ten plik (grep "wp-config.php" access.log), a jeśli tak albo jeśli logu nie masz, zmień hasło użytkownika bazy i wygeneruj nowe klucze i sole (generator WordPress.org). Nowe sole wylogują wszystkich użytkowników, co w tej sytuacji jest zaletą. Zmianę wersji PHP razem z tym sprawdzeniem robię w ramach opieki nad stronami WordPress.

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

Stan na 22 października 2026 roku, około 08:00 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, Automattic, Patchstack i Huntress. Komunikat informacyjny php.net z 23 października (CVE-2026-115560) dodałem 24 października 2026 roku.