Krytyczne luki w PHP (CVE-2026-109618/109619): jak sprawdzić, czy hosting je załatał

Autor: Grzegorz Wojterzak. Aktualizacja: 4 listopada 2026. Czas czytania: około 11 minut.

Większość poradników o bezpieczeństwie WordPressa kończy się na „aktualizuj wtyczki”. Tym razem to nie wystarczy. Luka siedzi piętro niżej, w PHP, czyli programie, który na serwerze wykonuje kod WordPressa, WooCommerce i większości stron w internecie. Twój panel może być w idealnym porządku, a strona i tak narażona.

Wyjaśniam, co się stało, kto odpowiada za poprawkę, jak sprawdzić wersję i nie dać się zmylić numerowi, co napisać do hostingu i co zrobić, jeśli strona działa na starym PHP.

Co się stało i dlaczego to poważne

Według komunikatu na php.net obie luki pozwalają na zdalne wykonanie kodu bez uwierzytelnienia. Mówiąc prościej: obca osoba może wysłać do Twojej strony odpowiednio spreparowane żądanie i uruchomić na serwerze własny program, bez hasła i bez konta. Obie dostały ocenę 9,2 w skali CVSS 4.0, czyli krytyczną. W mediach nazywa się je zbiorczo „PHP2Shell”.

• CVE-2026-109618 dotyczy sytuacji, gdy PHP w trakcie obsługi żądania zabraknie pamięci. Część danych zostaje wtedy przygotowana tylko w połowie, a sprzątanie po żądaniu traktuje je jak poprawne.
• CVE-2026-109619 dotyczy danych, które po zakończonym żądaniu powinny zniknąć, a zostają w procesie PHP i mogą zostać użyte przy obsłudze kolejnego żądania.

PHP.net wymienia jako narażone wszystkie sposoby uruchamiania PHP na serwerach WWW: PHP-FPM, moduł Apache (mod_php), php-cgi, FrankenPHP i LiteSpeed. Największe ryzyko według PHP.net dotyczy mod_php, gdzie wykazano atak działający, zanim w ogóle uruchomi się kod strony. Według Patchstack badacze z firmy Wiz pokazali skuteczny atak na aktualnego WordPressa, a odczyt pamięci może ujawniać hasła, tokeny i klucze API z innych żądań.

Oś czasu

• 20 października: PHP zapowiada pilne wydanie poprawek na 21 października, 14:00 UTC.
• Noc z 20 na 21 października: szczegóły luk wyciekają przed planowaną publikacją.
• 21 października rano: według Patchstack hostingi partnerskie zgłaszają pierwsze aktywne ataki, a Cloudflare informuje o pierwszych próbach i wdraża reguły zapory.
• 21 października, 13:52 UTC (15:52 czasu polskiego): PHP publikuje wersje z poprawkami.

Według doniesień medialnych analitycy Amazon Web Services twierdzą, że co najmniej jedna grupa wykorzystywała luki już od 17 października, czyli przed wyciekiem. Nie znalazłem tego potwierdzenia w źródle pierwotnym, ale wniosek jest taki sam: przy serwerach, które łatano z opóźnieniem, warto sprawdzić, czy nic się nie stało.

Kto naprawia: Ty, hosting czy administrator

To najważniejsza rzecz do zrozumienia. Strona internetowa składa się z warstw, a za każdą odpowiada ktoś inny.

• Hosting współdzielony (typowy pakiet w home.pl, nazwa.pl, cyber_Folks, LH.pl i podobnych): PHP aktualizuje hosting. Twoja rola to sprawdzić, czy to zrobił, i wybrać w panelu wspieraną gałąź.
• VPS lub serwer dedykowany, np. w OVH: jeśli hosting nie zarządza serwerem za Ciebie, PHP aktualizujesz Ty albo Twój administrator. Nikt inny tego nie zrobi.
• Hosting zarządzany dla WordPressa: zwykle jak współdzielony, ale sprawdź w umowie lub zapytaj.

Jak sprawdzić wersję PHP i nie dać się zmylić numerowi

Najprościej w panelu WordPressa: Narzędzia → Stan witryny → Informacja, sekcja Serwer, wiersz Wersja PHP (w wersji angielskiej Tools → Site Health → Info, Server, PHP version).

Jeśli masz sklep, tę samą informację pokazuje WooCommerce → Status → Status systemu, sekcja Środowisko serwerowe. Uwaga: zielony kolor numeru oznacza tu tylko, że wersja spełnia wymagania WooCommerce. Nie mówi nic o lukach bezpieczeństwa.

Wersje z poprawką

Dane z php.net, stan na początek listopada 2026.

Na własnym serwerze: sprawdź numer pakietu

Jeśli masz VPS z Ubuntu albo Debianem i PHP z oficjalnych pakietów systemu, sam numer wersji niewiele powie. Ubuntu i Debian zwykle dokładają poprawki do wersji, którą wydały razem z systemem, bez zmiany numeru PHP. Tak wygląda to na serwerze z naszą instalacją testową (Ubuntu 24.04):

$ php -v | head -1
PHP 8.3.6 (cli) (built: Sep  2 2026 12:56:02) (NTS)
$ dpkg -l php8.3-cli | tail -1 | awk '{print $2, $3}'
php8.3-cli 8.3.6-0ubuntu0.24.04.11

Pierwsze polecenie pokazuje wersję i datę kompilacji: 2 września 2026, czyli przed poprawkami. Drugie pokazuje numer pakietu. Ubuntu opisało poprawkę w komunikacie bezpieczeństwa USN-8948-1: dla Ubuntu 24.04 to pakiet 8.3.6-0ubuntu0.24.04.13, więc serwer testowy z numerem kończącym się na .11 poprawki jeszcze nie ma. Porównaj swój numer pakietu z numerem podanym tam dla Twojej wersji systemu, a na Debianie z komunikatem DSA lub DLA. Patchstack zwraca uwagę, że w części repozytoriów dziennik zmian mówi tylko „nowa wersja”, więc porównuj numery, a nie szukaj słowa „CVE”.

Po aktualizacji pakietów zrestartuj PHP-FPM albo serwer WWW. PHP.net podkreśla, że stare procesy PHP, które działały przed aktualizacją, nadal używają starego kodu. Wersję w raporcie Stan witryny sprawdzaj dopiero po restarcie.

Kilka wersji PHP na jednym koncie

Na wielu hostingach każda domena może mieć inną wersję PHP. Sprawdź każdą stronę osobno, także kopię testową i stare instalacje w podkatalogach, o których wszyscy zapomnieli. Luka nie wymaga logowania, więc zapomniany sklep testowy na PHP 8.1 to taka sama furtka do konta hostingowego jak strona główna.

Wzór maila do hostingu

Na hostingu współdzielonym nie zobaczysz, czy PHP ma poprawki dodane przez dostawcę. Zapytaj wprost. Ten tekst możesz skopiować i uzupełnić:

Temat: Luki w PHP CVE-2026-109618 i CVE-2026-109619 – konto [login / domena]

Dzień dobry,

proszę o informację, czy PHP na serwerze obsługującym moje konto
[login] i domeny [domena1, domena2] ma poprawki luk CVE-2026-109618
i CVE-2026-109619 opublikowanych przez PHP 21.10.2026.

W raporcie Stan witryny widzę wersję PHP [np. 8.3.6]. Proszę o potwierdzenie:
1. czy poprawki są wgrane dla wszystkich wersji PHP dostępnych
   w panelu, w tym [gałąź, której używam],
2. od kiedy (data i godzina) serwer ma poprawki,
3. czy procesy PHP zostały po aktualizacji uruchomione ponownie,
4. czy w logach serwera widzieliście próby wykorzystania tych luk
   na moim koncie.

Z góry dziękuję,
[imię i nazwisko, numer klienta]

Pytanie o datę ma znaczenie. Jeśli serwer dostał poprawkę 21 października wieczorem, ryzyko jest małe. Jeśli tydzień później, warto przejrzeć stronę.

Masz PHP 7.4, 8.0 albo 8.1

Te wersje nie dostają już wydań od projektu PHP. Ze względu na wagę luk zespół bezpieczeństwa PHP udostępnił minimalne poprawki w kodzie źródłowym dla 7.4, 8.0 i 8.1, z przeznaczeniem dla osób, które same kompilują PHP. Niektóre dystrybucje Linuksa i firmy oferujące rozszerzone wsparcie wydały własne pakiety z poprawkami. Czy Twój hosting z nich skorzystał, wie tylko on.

Co zrobić:

1. Zapytaj hosting

   Użyj wzoru maila wyżej i dopisz, że chodzi o PHP 7.4, 8.0 lub 8.1.

2. Zaplanuj przejście na PHP 8.3 lub 8.4

   Najpierw na kopii strony. Plan krok po kroku opisuję w poradniku Koniec PHP 8.2: jak przejść na 8.3. To samo dotyczy PHP 8.2, który traci wsparcie 31 grudnia 2026.

3. Jeśli coś się posypie, cofnij wersję i napraw kod

   Najczęstsze błędy po zmianie PHP i sposób ich naprawy znajdziesz w poradniku Strona nie działa po zmianie PHP.

Przy okazji: WordPress 7.0 i nowszy wymaga co najmniej PHP 7.4, a strony na starszym PHP utknęły na gałęzi 6.9. O jej poprawkach piszę w artykule o WordPressie 7.1.4.

Po poprawce: czy ktoś zdążył wejść

Ataki zgłaszano, zanim poprawki były dostępne. Dlatego po potwierdzeniu, że PHP jest załatane, zrób krótki przegląd:

• lista administratorów w menu Użytkownicy (nowe konta, nieznane adresy e-mail),
• lista wtyczek, także zakładka Wymuszane (Must-Use),
• nowe pliki PHP w wp-content/uploads i w katalogu głównym, z datą od 17 października,
• nietypowe przekierowania, spam w wynikach Google, ostrzeżenia hostingu.

Patchstack wymienia jako możliwe sygnały ataku m.in. błędy 500 i błędy braku pamięci po dużych żądaniach z plikami oraz niewyjaśnione restarty procesów PHP. Same w sobie niczego nie dowodzą, ale jeśli je widzisz, a serwer był długo bez poprawki, potraktuj go jako możliwie przejęty. Wtedy zmień hasła do bazy danych, klucze API zapisane w konfiguracji i klucze bezpieczeństwa WordPressa w wp-config.php. Pełną listę objawów włamania opisuję w poradniku Jak sprawdzić, czy strona jest zhakowana.

Jak reagować na każdą lukę w oprogramowaniu serwera

PHP2Shell nie jest pierwszą i nie będzie ostatnią luką w oprogramowaniu, którego nie widać w panelu WordPressa. Przy następnej (w PHP, serwerze WWW, bazie danych, OpenSSL) ten sam schemat oszczędzi Ci nerwów:

1. Wiedz, na czym stoi strona

   Zapisz w jednym miejscu: hosting, rodzaj usługi (współdzielony czy VPS), wersję PHP, bazę danych, kto ma dostęp do serwera. Raport Stan witryny pokazuje większość tych danych w sekcjach Serwer i Baza danych.

2. Ustal, kto aktualizuje którą warstwę

   Na hostingu współdzielonym system i PHP to obowiązek hostingu. Na VPS bez umowy o zarządzanie to Twój obowiązek, nawet jeśli serwer stawiał wykonawca, który już się nie odzywa.

3. Pytaj o fakty, nie o zapewnienia

   Odpowiedź „wszystko jest bezpieczne” to za mało. Pytaj o wersję, datę wdrożenia i restart usług.

4. Nie szukaj łatki we wtyczce

   Luk w serwerze nie naprawia się z poziomu WordPressa. Wtyczki mogą co najwyżej dodać zaporę dla części ataków.

5. Po wszystkim sprawdź stronę

   Przy lukach wykorzystywanych przed publikacją poprawki krótki przegląd to rozsądne minimum.

Kiedy nie robić tego samemu

• masz VPS, a nikt nie wie, jak na nim zainstalowano PHP ani jak je aktualizować,
• hosting nie odpowiada albo odpowiada ogólnikami, a strona to sklep z danymi klientów,
• strona działa na PHP 7.4–8.1 i boisz się, że zmiana wersji ją wyłączy,
• widzisz błędy 500, nowe pliki PHP albo nieznane konta, a serwer był długo bez poprawki.

Najczęstsze pytania