Luka w PHP (PHP2Shell): co sprawdzić i zlecić hostingowi

21 października 2026 r. twórcy PHP wydali awaryjne poprawki dwóch krytycznych luk w samym PHP, nazwanych PHP2Shell. Na PHP działają WordPress, WooCommerce, PrestaShop i wiele stron pisanych na zamówienie. Jeśli Twoja strona korzysta z któregoś z nich, ta sprawa dotyczy także Ciebie. Dobra wiadomość: poprawka jest gotowa, a sprawdzenie, czy ją masz, zajmuje kilka minut.

W tej poradzie znajdziesz: co się stało, jak sprawdzić wersję PHP bez programisty, co zrobić dziś i co zlecić hostingowi albo wykonawcy strony. Opisuję stan wiedzy na 30 października 2026 r. Wersje z poprawką mogą się jeszcze zmienić, więc przed aktualizacją sprawdź je w komunikacie bezpieczeństwa na php.net.

Co się stało

W PHP znaleziono dwa błędy w obsłudze pamięci: CVE-2026-109618 i CVE-2026-109619. Odpowiednio przygotowane zapytanie do strony może sprawić, że serwer wykona cudzy kod. Atakujący nie musi się logować ani znać żadnego hasła. Wystarczy, że strona działa na podatnej wersji PHP.

Zespół PHP ocenił obie luki na 9,2 w skali CVSS od 0 do 10, czyli jako krytyczne. Firma Patchstack opisała zgłoszenia ataków od firm hostingowych jeszcze kilka godzin przed wydaniem poprawek, a 26 października amerykańska agencja CISA wpisała obie luki do katalogu podatności wykorzystywanych w atakach (KEV). CERT Polska wydał w tej sprawie komunikat.

Nie ma powodu do paniki, ale jest powód, żeby sprawdzić stronę jeszcze dziś.

Kogo dotyczy luka w PHP

Luka siedzi w samym PHP, a nie we wtyczce czy motywie. Dlatego dotyczy każdej strony, która działa na PHP:

• WordPress i WooCommerce, niezależnie od wtyczek i motywu,
• PrestaShop, Joomla i inne systemy stron i sklepów napisane w PHP,
• własne skrypty i formularze w PHP, także na prostych stronach,
• narzędzia na serwerze, takie jak phpMyAdmin.

Według komunikatu PHP zagrożone są wszystkie instalacje PHP, które obsługują strony, niezależnie od sposobu uruchomienia na serwerze. Ważne: aktualizacja WordPressa ani wtyczek tego nie naprawi. Poprawkę trzeba wgrać do PHP na serwerze, a na zwykłym hostingu robi to dostawca.

Wersje 8.1 i starsze nie dostają już wydań od twórców PHP. Przy tak poważnych lukach zespół PHP przygotował dla 7.4, 8.0 i 8.1 tylko minimalne łatki dla osób, które same kompilują PHP. Na typowym hostingu nie licz na to: bezpieczne wyjście to przejście na 8.3 lub 8.4.

Jak sprawdzić, czy Twoja strona jest narażona

Liczy się pełny numer wersji, z trzecią liczbą na końcu. Samo „8.3” nie wystarczy: wersja 8.3.35 jest podatna, a 8.3.36 już nie.

WordPress: bez logowania na serwer

1. Zaloguj się do panelu WordPressa.
2. Wejdź w Narzędzia → Stan witryny i otwórz zakładkę Informacja.
3. Rozwiń sekcję Serwer. Przy pozycji „Wersja PHP” zobaczysz pełny numer, na przykład 8.3.36.

W PrestaShopie wersję PHP znajdziesz w parametrach zaawansowanych, w informacjach o konfiguracji sklepu.

Panel hostingu

W panelu hostingu, w ustawieniach PHP, zwykle widać tylko „8.3” albo „8.4”, bez trzeciej liczby. To wystarczy, żeby sprawdzić, czy strona nie działa na wersji bez wsparcia (8.1 lub starszej). O pełny numer i poprawkę zapytaj hosting, gotowa wiadomość jest niżej. Gdzie zmienić wersję w panelach OVHcloud, home.pl i nazwa.pl, opisuję w poradzie o końcu wsparcia PHP 8.2.

Plik testowy, tylko na chwilę

Jeśli masz dostęp do serwera przez FTP, wgraj plik wersja.php o takiej treści:

<?php
echo PHP_VERSION;

Otwórz go w przeglądarce, zapisz wynik i od razu usuń plik. Nie zostawiaj na serwerze także pliku z phpinfo(): to gotowa ściągawka dla każdego, kto szuka słabych punktów.

Uwaga na serwery z Ubuntu

Na serwerach VPS, na których PHP pochodzi z pakietów systemu, numer bywa mylący. Ubuntu wgrywa poprawkę do starszej wersji i zostawia jej główny numer. W Ubuntu 24.04 poprawiony pakiet ma numer 8.3.6-0ubuntu0.24.04.13, a nie 8.3.36. W takim przypadku o stan poprawki pytasz administratora serwera albo wykonawcę strony.

Co zrobić dziś

1. Sprawdź wersję PHP jednym ze sposobów powyżej i porównaj ją z tabelą.
2. Jeśli wersja jest niższa niż w tabeli, napisz do hostingu. Na hostingu współdzielonym PHP aktualizuje dostawca, nie Ty.
3. Jeśli masz PHP 8.1 lub starsze, zmień wersję na 8.3 lub 8.4 jak najszybciej: kopia, test na kopii strony, zmiana w panelu. To nie jest jedno kliknięcie, bo stare wtyczki mogą przestać działać. CISA zaleca, żeby do tego czasu wyłączyć takie strony, chyba że hosting potwierdzi poprawkę dla Twojej wersji w pakiecie systemu.
4. Jeśli masz PHP 8.2, wersja 8.2.35 zamyka te luki, ale wsparcie 8.2 kończy się 31 grudnia 2026 r. To dobry moment, żeby od razu przejść na nowszą wersję.
5. Zrób świeżą kopię zapasową plików i bazy danych i zapisz ją poza serwerem.
6. Przy okazji zaktualizuj WordPressa, motyw i wtyczki według poradnika bezpiecznej aktualizacji. Nie naprawi to PHP, ale zamknie inne drogi wejścia.
7. Nie instaluj „wtyczek naprawiających PHP2Shell” ani skryptów z forów. Wtyczka nie zmieni PHP na serwerze, a nieznany kod może zawierać złośliwe oprogramowanie.

Wiadomość do hostingu, do skopiowania:

Dzień dobry, moja strona [adres strony] działa na Państwa hostingu (konto: [login lub numer klienta]). Proszę o potwierdzenie, że PHP na moim koncie ma już poprawki luk PHP2Shell (CVE-2026-109618 i CVE-2026-109619), czyli wersję co najmniej 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 albo pakiet systemu z tą poprawką, i że procesy PHP zostały po aktualizacji uruchomione ponownie. Proszę też o informację, czy w logach serwera od 20 października widać próby ataku na moją stronę. Dziękuję.

Jeśli hosting po kilku dniach nie potwierdza aktualizacji, a w panelu nie ma nawet wersji 8.3 ani 8.4, to sygnał, żeby zmienić dostawcę. W ramach usługi domena i hosting (od 390 zł netto rocznie) przenoszę stronę na serwer w Polsce lub UE z aktualnym PHP.

Co zlecić wykonawcy strony albo administratorowi serwera

Jeśli strona działa na serwerze VPS, w kontenerze albo na serwerze wykonawcy, PHP aktualizuje osoba, która tym serwerem zarządza. Lista dla niej:

• Aktualizacja PHP do wersji z tabeli albo do poprawionego pakietu dystrybucji (Ubuntu: USN-8948-1, Debian 13: DSA-6574-1, Debian 12: DLA-4848-1).
• Restart wszystkich procesów PHP (PHP-FPM, Apache z mod_php). Bez restartu stara wersja dalej działa w pamięci.
• Najpierw Apache z mod_php. Zespół PHP ocenia, że tam ryzyko jest najwyższe.
• Obrazy Dockera z PHP trzeba przebudować na nowej wersji i wdrożyć ponownie.
• Zapora aplikacyjna (WAF) może według CISA częściowo ograniczyć ryzyko do czasu aktualizacji, ale jej nie zastępuje.
• Serwery z Windows: 26 października PHP wydało przebudowane paczki 8.5.12-1, 8.4.27-1, 8.3.36-1 i 8.2.35-1 z poprawioną biblioteką Brotli (CVE-2026-111497). O tej luce piszę w poradzie Luka w Node.js i Brotli (Node2Shell).

Jeśli aktualizacja musi poczekać, komunikat PHP podaje tymczasowe ustawienie. Trzeba je wpisać w php.ini albo w konfiguracji puli PHP-FPM (nie przez ini_set() ani plik .user.ini) i zrestartować procesy PHP:

session.upload_progress.enabled = 0

To tylko częściowa ochrona. Według zespołu PHP blokuje potwierdzone ścieżki ataku przez sesję, ale nie wszystkie warianty, a według Tanium nie chroni przed CVE-2026-109618. Pełną ochronę daje tylko aktualizacja.

Trzecia luka: CVE-2026-115560

23 października zespół PHP opisał kolejną lukę, także związaną z postępem wysyłania plików w sesji. Wersje z 21 października jej nie usuwają. Według PHP zagraża tylko przy nietypowym połączeniu ustawień serwera i kodu aplikacji, dlatego poprawka trafi do kolejnego regularnego wydania, a nie do awaryjnego.

Do tego czasu PHP zaleca ustawienie session.upload_progress.enabled = 0, to samo co wyżej. Jeśli to ustawienie już działa na serwerze, zostaw je także po aktualizacji. Po zmianie sprawdź formularze, w których klienci wysyłają pliki. W dniu, w którym kończę tę poradę, poprawki jeszcze nie ma, więc zajrzyj do aktualności na php.net.

Czy ktoś mógł już wejść na stronę

Pierwsze próby ataków odnotowano, zanim poprawki w ogóle się ukazały. Dlatego po aktualizacji warto sprawdzić, czy nikt nie zdążył zostawić sobie furtki. Sygnały ostrzegawcze:

• nowe konta administratorów, których nikt w firmie nie zakładał,
• nieznane pliki na serwerze, zwłaszcza pliki .php w katalogu z obrazkami,
• przekierowania na obce strony albo dziwne podstrony w wynikach Google,
• komunikaty hostingu o złośliwym oprogramowaniu albo nagły wzrost obciążenia serwera.

Poproś hosting albo wykonawcę o przegląd logów od 20 października. CISA zwraca uwagę między innymi na procesy PHP, które uruchamiają powłokę systemu albo pobierają narzędzia. Jeśli znajdziesz ślady włamania, zmień hasła, przywróć czystą kopię i zgłoś incydent do CERT Polska przez formularz na incydent.cert.pl. Plan działania krok po kroku opiszę w osobnej poradzie „Luka w stronie firmy: co robić w pierwszych 24 godzinach”.

Podsumowanie

PHP2Shell to dwie krytyczne luki w samym PHP, a nie w WordPressie czy wtyczkach. Sprawdź pełny numer wersji PHP, porównaj go z tabelą i poproś hosting o potwierdzenie poprawki. Ustawienia zastępcze tylko zmniejszają ryzyko, pełną ochronę daje aktualizacja.

Jeśli nie chcesz pilnować tego samodzielnie, w ramach opieki technicznej monitoruję stronę, robię kopie zapasowe i wgrywam aktualizacje bezpieczeństwa, pilne w 2 dni. Pakiet Czuwanie kosztuje od 149 zł netto miesięcznie, a Standard (od 349 zł) i Pro (od 749 zł) dają szybszą reakcję i godziny prac w miesiącu. Gdy chcesz sprawdzić, jak strona jest zabezpieczona poza samym PHP, zamów audyt bezpieczeństwa albo po prostu napisz do mnie. Odpowiadam w 24 godziny, a nowi klienci dostają 20% rabatu na pierwsze zlecenie.