Krytyczne luki w PHP (PHP2Shell): co zrobić ze stroną WordPress?

Stan na: 22 października 2026

21 października 2026 r. zespół PHP wydał wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, które łatają dwie krytyczne luki: CVE-2026-109618 i CVE-2026-109619. Obie mają ocenę CVSS 9,2 i pozwalają przejąć serwer bez logowania. Dotyczą stron na WordPressie, sklepów WooCommerce i PrestaShop oraz każdej innej aplikacji działającej na PHP.

Najważniejsze informacje w skrócie

• Zespół PHP zapowiedział wydanie poprawek 20.10.2026, a opublikował je 21.10.2026 o 14:00 UTC, czyli o 16:00 czasu polskiego.
• Obie luki pozwalają na zdalne wykonanie kodu bez uwierzytelnienia i mają ocenę 9,2 w skali CVSS v4.0.
• Według CERT Polska podatne są wszystkie wersje PHP od 5.4 w górę.
• Aktualizacja WordPressa ani wtyczek nie usuwa problemu. Trzeba zaktualizować sam interpreter PHP i zrestartować PHP-FPM lub Apache.
• PHP 8.1 i starsze nie dostają już oficjalnych wydań, a PHP 8.2 traci wsparcie 31 grudnia 2026 r.

Co się stało z PHP w październiku 2026?

W dniach 20-21 października 2026 r. zespół PHP ujawnił i załatał dwie krytyczne podatności w samym silniku PHP, nazwane przez badaczy PHP2Shell. 20 października PHP Foundation ogłosiła z wyprzedzeniem, że dzień później wyda poprawki dwóch luk ocenionych na 9,2 w skali CVSS v4.0. 21 października CERT Polska wydał dwa komunikaty dla administratorów i właścicieli stron.

Czym są luki CVE-2026-109618 i CVE-2026-109619?

CVE-2026-109618 i CVE-2026-109619 to dwie podatności typu RCE (zdalne wykonanie kodu) w interpreterze PHP, związane z obsługą błędów pamięci i błędów krytycznych. Nie są to błędy w WordPressie, motywie ani wtyczce, tylko w warstwie, na której te aplikacje działają.

Pierwsza luka (CVE-2026-109618) dotyczy sytuacji, w której zapytanie wyczerpuje limit pamięci w niefortunnym momencie. PHP zostawia wtedy częściowo zainicjowane dane, a przy sprzątaniu traktuje je jako poprawne. Druga luka (CVE-2026-109619) polega na tym, że po błędzie krytycznym w pamięci procesu zostaje stan z poprzedniego zapytania. Kolejne zapytanie obsłużone przez ten sam proces może z niego skorzystać, zanim zostanie on wyczyszczony.

Czy moja strona na WordPressie jest zagrożona?

Tak, jeśli serwer obsługuje stronę niezałataną wersją PHP. Badacze Wiz pokazali przejęcie serwera bez logowania na najnowszych obrazach WordPressa, Drupala i Joomli, a podkreślają, że do ataku wystarczy nawet prosta aplikacja typu „Hello World” na podatnej wersji PHP. Bezpieczny kod strony i aktualne wtyczki nie chronią przed błędem w samym interpreterze.

Zespół PHP wskazuje jako zagrożone wszystkie instalacje obsługujące zapytania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Największe ryzyko dotyczy mod_php, gdzie atak działa jeszcze przed uruchomieniem kodu aplikacji. Druga konsekwencja jest mniej widowiskowa, ale równie poważna. Luka pozwala odczytać fragmenty pamięci procesu PHP, w których mogą być hasła, tokeny sesji i klucze API innych użytkowników. Dla sklepu internetowego oznacza to ryzyko wycieku danych klientów i dostępów do bramek płatności lub integracji.

Które wersje PHP są podatne, a które mają poprawkę?

Poprawki dostały tylko wspierane gałęzie PHP od 8.2 do 8.5. Bezpieczna jest wersja równa lub wyższa od wersji z poprawką w danej gałęzi. Starsze wersje są podatne, a ich zabezpieczenie zależy od dostawcy hostingu lub dystrybucji Linuksa.

Dla PHP 7.4, 8.0 i 8.1 zespół PHP przygotował minimalne poprawki kodu źródłowego, z których mogą skorzystać osoby kompilujące PHP samodzielnie. Część hostingów zabezpiecza też starsze linie przez pakiety CloudLinux. Tak zrobił dhosting.pl, który objął poprawkami wersje od 5.3 do 8.5.

Jak sprawdzić wersję PHP na swojej stronie?

Wersję PHP sprawdzisz w panelu hostingu, w kokpicie WordPressa albo poleceniem php -v na serwerze. W WordPressie wejdź w Narzędzia, następnie Zdrowie witryny, zakładka Informacje i sekcja Serwer. Tam zobaczysz pełny numer wersji, na przykład 8.3.36.

Liczy się pełny numer, a nie sama gałąź. Wersja 8.3.30 i wersja 8.3.36 to ta sama gałąź, ale tylko druga ma poprawkę. Jeśli korzystasz z pliku phpinfo do sprawdzenia konfiguracji, usuń go od razu po odczycie, bo publicznie dostępny plik phpinfo ujawnia szczegóły serwera.

Co zrobić krok po kroku?

Pierwszym i jedynym pełnym rozwiązaniem jest instalacja wersji PHP z poprawką na każdym serwerze i restart wszystkich procesów PHP. Pozostałe kroki ograniczają ryzyko do czasu aktualizacji albo pomagają wykryć ślady ataku.

1. Krok 1: sprawdź wersję PHP. Porównaj pełny numer wersji z tabelą 2. Zrób to dla każdej strony, sklepu i środowiska testowego, bo wersje PHP bywają różne na różnych kontach.
2. Krok 2: sprawdź komunikat hostingu. Na hostingu współdzielonym poprawki instaluje dostawca. Szukaj komunikatu na blogu lub w panelu klienta, tak jak w przypadku dhostingu. Gdy komunikatu nie ma, zapytaj wsparcie wprost o CVE-2026-109618 i CVE-2026-109619.
3. Krok 3: zaktualizuj PHP na VPS lub serwerze dedykowanym. Zainstaluj pakiety z poprawką od dystrybucji i zrestartuj Apache, PHP-FPM oraz inne długo działające procesy PHP. Zespół PHP zaznaczył, że repozytorium rpms.remirepo.net nie miało poprawek w dniu wydania.
4. Krok 4: zastosuj obejścia, jeśli nie możesz zaktualizować od razu. CERT Polska zaleca ustawienie w php.ini: memory_limit na -1 (albo co najmniej 128M), post_max_size na 8M lub mniej, max_input_vars na 1000 lub mniej oraz session.upload_progress.enabled na Off. Ustawienia wpisz w php.ini lub konfigurację puli FPM, a nie przez ini_set() czy .user.ini, i zrestartuj procesy.
5. Krok 5: zaktualizuj WordPressa, motywy i wtyczki. To nie łata PHP2Shell, ale zamyka inne drogi wejścia. Na to samo zwraca uwagę dhosting.pl w swoim komunikacie.
6. Krok 6: sprawdź ślady ataku. Wiz wskazuje sygnały ostrzegawcze: nietypowe zapytania multipart zakończone błędami limitu pamięci, serie odpowiedzi HTTP 500, nienaturalnie duże ciasteczka PHPSESSID i częste restarty procesów PHP . Ślady wykorzystania luki zgłoś do CERT Polska przez incydent.cert.pl.

Kto instaluje poprawkę: hosting czy właściciel strony?

To zależy od rodzaju serwera. Na hostingu współdzielonym poprawkę instaluje dostawca hostingu, na VPS i serwerze dedykowanym administrator serwera, a w gotowych urządzeniach i obrazach Dockera producent tego oprogramowania.

Przykład szybkiej reakcji po stronie hostingu: dhosting.pl wyłączył parametr session.upload_progress.enabled jeszcze przed publikacją poprawek, pierwsze serwery zaktualizował 21.10.2026 o 16:05, a całą infrastrukturę 22.10.2026 o 3:57. Klienci tego hostingu nie muszą samodzielnie instalować serwerowych aktualizacji.

Czy obejścia w php.ini wystarczą?

Nie. Ustawienia w php.ini zmniejszają ryzyko tylko dla wybranych ścieżek ataku i nie czynią instalacji bezpieczną. Zespół PHP wprost pisze, że jedynym kompletnym rozwiązaniem jest aktualizacja.

Obejścia mają też koszt. Ustawienie memory_limit na -1 przenosi kontrolę nad pamięcią na system operacyjny, więc proces, który zużyje zbyt dużo pamięci, może zostać zabity, a strona chwilowo przestanie odpowiadać. Niski post_max_size może z kolei zablokować przesyłanie większych plików przez formularze. Te zmiany warto traktować jako most na kilka godzin, nie jako stan docelowy.

Dlaczego eksperci spodziewają się szybkich ataków?

Eksperci spodziewają się ataków, ponieważ szczegóły luk wyciekły przed premierą poprawek, a pierwsze exploity pojawiły się w dniu wydania. Firma Sansec przewidywała, że masowe próby ataków mogą ruszyć w ciągu 15 minut od publikacji poprawek. Sekurak donosił 21 października o pierwszych exploitach.

PHP Foundation opisała przebieg wycieku: identyfikatory CVE trafiły do sieci 20 października, a firma Chainguard opublikowała gotowe obrazy z poprawką ponad sześć godzin przed oficjalnym wydaniem, co dało atakującym czas na analizę łatki. Według szacunków przywołanych przez badaczy problem może dotyczyć około 1,3 mln serwerów dostępnych z internetu, choć nie jest to potwierdzona liczba podatnych maszyn.

Najczęstsze błędy przy łataniu PHP2Shell

• Aktualizacja samego WordPressa. Nowa wersja WordPressa nie zmienia interpretera PHP. Sprawdź wersję PHP osobno.
• Sprawdzenie tylko gałęzi. „Mamy PHP 8.3” nic nie mówi o poprawce. Porównaj pełny numer, na przykład 8.3.36.
• Brak restartu po aktualizacji. Działające procesy PHP-FPM i Apache dalej używają starego kodu, dopóki ich nie zrestartujesz.
• Obejścia przez ini_set() lub .user.ini. Te ustawienia działają za późno, po rozpoczęciu obsługi zapytania. Wpisz je w php.ini lub konfigurację puli FPM.
• Zostawienie PHP 7.4 lub 8.0, bo „działa”. Te wersje nie dostają oficjalnych wydań. Zaplanuj przejście na PHP 8.4 lub 8.5 i przetestuj zgodność wtyczek.
• Pominięcie środowiska testowego. Kopia strony na subdomenie lub osobnym koncie może działać na innej, starszej wersji PHP. Sprawdź każde środowisko osobno.

Przykładowy scenariusz: sklep WooCommerce na VPS

Przykładowy scenariusz pokazuje, jak wygląda reakcja w praktyce. Sklep z odzieżą działa na WordPressie z WooCommerce na VPS z PHP 8.2.30 i Apache z mod_php. To konfiguracja z najwyższym ryzykiem według zespołu PHP.

Administrator rano 22 października sprawdza wersję w Zdrowiu witryny i widzi 8.2.30. Instaluje pakiet PHP 8.2.35 z repozytorium dystrybucji, restartuje Apache i potwierdza nową wersję. Następnie przegląda logi z ostatnich 24 godzin pod kątem błędów limitu pamięci i serii odpowiedzi 500. Logi są czyste, więc kończy na aktualizacji wtyczek. Gdyby znalazł ślady, zmieniłby hasła administratorów, klucze API bramki płatności i zgłosił incydent do CERT Polska. Na koniec zapisuje w planie migrację na PHP 8.4 przed końcem wsparcia PHP 8.2, czyli przed 31 grudnia 2026 r.

Jak to robimy w Special Space

Special Space prowadzi opiekę techniczną nad stronami WordPress w ramach Pakietu Opieki. Pakiet obejmuje aktualizacje rdzenia WordPressa, wtyczek i motywów po testach na środowisku stagingowym, codzienne kopie zapasowe przechowywane na zewnętrznym serwerze oraz monitoring bezpieczeństwa. Zgłoszenia krytyczne, w tym naruszenia bezpieczeństwa, obsługujemy w ciągu 24 godzin.

Przy takich lukach jak PHP2Shell zaczynamy od inwentaryzacji: sprawdzamy wersję PHP na każdej stronie i każdym środowisku, potwierdzamy z hostingiem instalację poprawek i weryfikujemy logi. Jeśli Twoja strona działa na podatnej wersji PHP, przeprowadzimy aktualizację, która obejmuje:

• aktualizację PHP do bezpiecznej wersji,
• sprawdzenie zgodności strony, wtyczek i modułów z nową wersją,
• testy poprawnego działania strony po aktualizacji,
• potwierdzenie zakończenia prac w osobnej wiadomości.

Koszt aktualizacji wstępnie szacujemy na 300-500 zł netto. Ostateczną kwotę potwierdzimy przed rozpoczęciem prac, jeśli analiza wykaże dodatkowe potrzeby, na przykład przestarzałe wtyczki niezgodne z nową wersją PHP.

Projektując nowe strony internetowe i sklepy internetowe, od początku zakładamy aktualną wersję PHP i plan aktualizacji. Jeśli prowadzisz sklep na PrestaShop, zajrzyj też do naszego poradnika o aktualizacji PrestaShop 1.7 do wersji 8 lub 9.

Podsumowanie

Luki CVE-2026-109618 i CVE-2026-109619 (PHP2Shell) to krytyczne błędy w samym silniku PHP, które pozwalają przejąć serwer bez logowania i odczytać dane z pamięci. Jedynym pełnym zabezpieczeniem jest wersja PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 lub nowsza w danej gałęzi oraz restart procesów PHP. Obejścia w php.ini kupują tylko czas. Właściciel strony powinien dziś sprawdzić pełny numer wersji PHP, potwierdzić aktualizację u hostingu i zaplanować odejście od PHP 8.2 i starszych.

Grafiki w artykule zostały wygenerowane przez AI.