php2shell: dwie krytyczne luki w PHP, poprawka 21 października o 16:00. Co zrobić ze stroną na WordPressie

20 października zespół bezpieczeństwa PHP opublikował na php.net zapowiedź: w środę 21 października 2026 o 14:00 UTC, czyli o 16:00 czasu polskiego, ukaże się wydanie poprawiające dwie krytyczne luki. Obie mają ocenę 9,2 w skali CVSS 4.0, której maksimum to 10. Zespół zastrzega, że wyda poprawkę wcześniej, jeśli szczegóły wyciekną albo pojawią się ślady wykorzystywania luk w sieci.

Na PHP działa praktycznie każdy WordPress i każdy sklep na WooCommerce. Uprzedzenie o poprawce z dniowym wyprzedzeniem zdarza się rzadko, więc nie należy tego lekceważyć. Poniżej opisujemy, co wiadomo, co trzeba zrobić dziś, zanim poprawka wyjdzie, i jak potem sprawdzić, że serwer naprawdę jej używa.

Co wiadomo po wycieku (php2shell)

Zapowiedź PHP nie wzięła się znikąd. 20 października rano na Hacker News pojawił się wpis o dwóch nadchodzących lukach w PHP. Wpis zniknął, ale zrzuty ekranu zdążyły się rozejść. Firma watchTowr potwierdziła, że luki są prawdziwe, i odtworzyła jedną z nich. Kilka godzin później PHP przyspieszył wydanie o dzień, na środę 21 października.

• Numery luk: CVE-2026-109618 i CVE-2026-109619. Wśród badaczy krąży nazwa php2shell.
• Typ: zdalne wykonanie kodu w samym PHP. W praktyce oznacza to, że ktoś może z zewnątrz uruchomić na serwerze własne polecenia.
• Wersje: na zrzucie narzędzia, który wyciekł razem z informacją, widnieje opis „działa na każdej wersji od PHP 5.4.0”. PHP tego jeszcze nie potwierdził, oficjalna lista wersji pojawi się z wydaniem.
• Ataki: według firmy Huntress na 20 października nie było śladów wykorzystywania luk w sieci. Sansec, który zajmuje się bezpieczeństwem sklepów internetowych, spodziewa się masowych ataków w ciągu 15 minut od wydania poprawki.

Które wersje PHP dostaną poprawkę

Poprawki bezpieczeństwa wychodzą tylko dla wersji, które PHP jeszcze wspiera. Dziś są to cztery gałęzie. Ich ostatnie wydania pochodzą z 24 września 2026, więc po 16:00 spodziewaj się kolejnych numerów w każdej z nich:

• PHP 8.5, obecnie 8.5.11, poprawki bezpieczeństwa do końca 2029 roku,
• PHP 8.4, obecnie 8.4.26, do końca 2028 roku,
• PHP 8.3, obecnie 8.3.35, do końca 2027 roku,
• PHP 8.2, obecnie 8.2.34, wsparcie kończy się 31 grudnia 2026, więc to jedna z ostatnich poprawek dla tej gałęzi.

PHP 8.1 i starsze (8.0, 7.4) nie dostaną poprawki od twórców PHP. Wsparcie 8.1 skończyło się 31 grudnia 2025. Niektóre dystrybucje Linuksa z płatnym, rozszerzonym wsparciem przenoszą poprawki do starszych wersji, ale na zwykłym hostingu współdzielonym na to nie licz. Jeśli informacje z wycieku się potwierdzą, starsze wersje będą podatne i zostaną bez poprawki. Strona na PHP 8.1 lub starszym wymaga więc dziś rozmowy z hostingiem: czy przeniesie stronę na wspieraną wersję, czy dostarczy własną poprawkę. Przejście na 8.3 lub 8.4 sprawdź najpierw na kopii roboczej, bo stare wtyczki i motywy potrafią się na nowszym PHP wysypać.

Krok 1, dziś: sprawdź, na jakim PHP działa strona

W WordPressie: Narzędzia → Zdrowie witryny → Informacje → Serwer. Pole „Wersja PHP” pokazuje wersję, której używa strona. To ważne, bo na jednym serwerze może być kilka wersji PHP, a polecenie w terminalu pokazuje tylko tę z wiersza poleceń, nie tę, która obsługuje stronę.

1# wersja PHP w wierszu poleceń (nie zawsze ta sama co strony)2php -v34# wersje PHP-FPM zainstalowane na serwerze (Debian/Ubuntu)5ls /etc/php/6systemctl list-units 'php*-fpm*' --no-pager

Krok 2, dziś: ustal, kto aktualizuje PHP

• Hosting współdzielony (LH.pl, home.pl, cyber_Folks, Zenbox i podobne): PHP aktualizuje dostawca. Ty wybierasz w panelu tylko gałąź, np. 8.3. Napisz dziś do supportu i zapytaj, kiedy wgrają poprawkę z 21 października. Konkretne pytanie zwykle dostaje konkretną odpowiedź.
• Serwer VPS lub dedykowany: PHP aktualizuje ten, kto administruje serwerem. Jeśli nie wiesz, kto to jest, to ten problem trzeba rozwiązać przed 16:00, a nie po.
• Obrazy Dockera: poprawka trafi do nowego obrazu, ale Twój kontener jej nie dostanie, dopóki obraz nie zostanie przebudowany i uruchomiony od nowa.
• Pakiety z repozytoriów (np. ondrej/php na Ubuntu, Remi na RHEL): pojawiają się zwykle kilka godzin po wydaniu, czasem później. Zaplanuj sprawdzenie wieczorem albo rano następnego dnia.

Krok 3, dziś: kopia zapasowa

Wydanie poprawkowe w tej samej gałęzi (np. z 8.3.35 na 8.3.36) zmienia tylko błędy, nie zachowanie języka, więc ryzyko, że strona przestanie działać, jest małe. Zrób jednak dziś kopię bazy i plików, zapisaną poza serwerem. Zajmie kwadrans, a jeśli po aktualizacji coś pójdzie nie tak, nie będziesz szukać jej w pośpiechu.

Krok 4, po 16:00: aktualizacja i ponowne uruchomienie PHP

Na VPS z Debianem lub Ubuntu aktualizacja wygląda zwykle tak (przykład dla PHP 8.3, numer gałęzi zmień na swój):

1sudo apt update2apt list --upgradable 2>/dev/null | grep php34sudo apt install --only-upgrade 'php8.3*'56# bez restartu PHP-FPM strona dalej działa na starej wersji7sudo systemctl restart php8.3-fpm

Najczęstszy błąd: pakiety są zaktualizowane, ale PHP-FPM działa dalej na starym kodzie, bo nikt go nie uruchomił ponownie. Ten sam problem dotyczy Apache z mod_php (wymaga restartu Apache) i LiteSpeed (restart lsws albo procesów lsphp).

Nie odkładaj tego na następny dzień. Jeśli prognoza Sansec się sprawdzi, pierwsze automatyczne próby ataku przyjdą, zanim większość administratorów skończy czytać ogłoszenie.

Krok 5: sprawdź, czy strona naprawdę używa nowej wersji

Wróć do Narzędzia → Zdrowie witryny → Informacje → Serwer i porównaj numer wersji z tym, który podał zespół PHP w ogłoszeniu wydania. Na hostingu współdzielonym zrób to samo po tym, jak dostawca potwierdzi aktualizację. Jeśli numer się nie zmienił, poprawki nie ma, niezależnie od tego, co twierdzi panel.

Po aktualizacji: czy ktoś nie zdążył przed Tobą

Huntress radzi szukać procesów, które PHP uruchamia, a nie powinien: powłoki (sh, bash), interpretera python lub perl, narzędzi curl, wget czy nc uruchomionych przez php-fpm, apache2 albo httpd. Na VPS szybki podgląd daje drzewo procesów. Warto też poszukać plików PHP, które w dniu wydania pojawiły się w katalogach tymczasowych i w wp-content/uploads.

1# procesy potomne PHP-FPM (powłoka albo curl pod php-fpm to zły znak)2ps -eo pid,ppid,user,cmd --forest | grep -A3 php-fpm34# pliki PHP w uploads zmienione w ostatnich 2 dniach5find wp-content/uploads -name '*.php' -mtime -2

Co z wtyczkami WordPressa

Luki są w samym PHP, nie w WordPressie, więc aktualizacja wtyczek ich nie załata. Nie musisz też dziś zmieniać gałęzi PHP, jeśli Twoja jest wspierana. Wystarczy poprawka w obrębie tej samej gałęzi. Zmiana gałęzi (np. z 8.1 na 8.3) to osobny projekt: wymaga sprawdzenia zgodności wtyczek i motywu na kopii roboczej, a nie robienia tego w pośpiechu tego samego dnia.