21 października 2026 roku administratorzy stron internetowych na całym świecie stanęli przed nietypowym problemem. Nie chodziło o awarię jednej firmy hostingowej ani o kolejną podatną wtyczkę do WordPressa. Wykryto dwie krytyczne luki w samym PHP, czyli środowisku, na którym działają miliony serwisów. Część organizacji profilaktycznie wyłączyła witryny, a zespoły bezpieczeństwa rozpoczęły pilne wdrażanie poprawek.
Zagrożenie otrzymało nazwę PHP2Shell. Podatności CVE-2026-109618 i CVE-2026-109619 oceniono na 9,2 punktu w dziesięciopunktowej skali CVSS 4.0. W określonych konfiguracjach mogą umożliwiać wykonanie kodu na serwerze bez znajomości hasła administratora. Problem dotyczy nie tylko instytucji publicznych: potencjalnie obejmuje także strony firmowe, sklepy WooCommerce, portale, aplikacje oraz panele napisane w PHP.
Czym jest PHP2Shell i dlaczego ta podatność jest tak poważna?
PHP2Shell nie jest nazwą wirusa, nieuczciwej wtyczki ani konkretnego ataku na panel logowania. To określenie grupy błędów odkrytych w podstawowym mechanizmie działania PHP. Według oficjalnego komunikatu PHP obie podatności mogą prowadzić do zdalnego wykonania kodu, określanego skrótem RCE (Remote Code Execution), bez wcześniejszego uwierzytelnienia.
To istotna różnica względem wielu typowych włamań na strony. Atakujący nie musi najpierw odgadnąć hasła, przejąć konta redaktora czy znaleźć błędu w formularzu konkretnej wtyczki. Wystarczy, że uda mu się wykorzystać podatne środowisko wykonawcze i spełnić warunki potrzebne do przeprowadzenia ataku. Nie oznacza to automatycznie, że każdą stronę da się przejąć jednym żądaniem, ale skala potencjalnych skutków uzasadnia najwyższy priorytet aktualizacji.
Na czym polegają luki CVE-2026-109618 i CVE-2026-109619?
CVE-2026-109618 dotyczy błędów obsługi braku dostępnej pamięci, czyli sytuacji określanej jako out of memory (OOM). W określonych warunkach PHP mogło pozostawić niepoprawnie zainicjalizowane wewnętrzne dane, a następnie potraktować je jako prawidłowe. CVE-2026-109619 wiąże się z pozostawaniem w pamięci nieaktualnego stanu po zakończeniu obsługi żądania. Kolejne żądanie mogło odwołać się do danych, których pamięć została wcześniej zwolniona.
Badacze Wiz Research wykazali nie tylko możliwość wykonania kodu, ale również odczytu informacji z pamięci procesu. Mogą znajdować się tam hasła, tokeny sesyjne czy klucze API. Nie oznacza to, że każda podatna witryna już ujawniła takie dane. Oznacza natomiast, że konsekwencje skutecznego wykorzystania błędu mogą wykraczać poza zmianę treści strony głównej.
Gdzie znajduje się luka PHP2Shell i w jaki sposób zagraża stronom internetowym?
Podatność PHP2Shell znajduje się wewnątrz silnika PHP, a nie w kodzie strony czy samego serwera WWW. Problemy dotyczą zarządzania pamięcią, obsługi błędów krytycznych i stanu wewnętrznego utrzymywanego między żądaniami. W określonych warunkach proces PHP może odwołać się do wcześniej zwolnionej pamięci, co umożliwia ujawnienie danych lub wykonanie nieautoryzowanego kodu.
Czy luka PHP2Shell dotyczy WordPressa?
Tak, instalacje WordPressa korzystające z podatnego PHP mogą być zagrożone, nawet gdy sam WordPress, motyw i wszystkie wtyczki są aktualne. Badacze potwierdzili możliwość wykorzystania problemu w środowiskach z WordPressem, Drupalem i Joomlą. Źródłem błędu nie był jednak kod tych systemów, lecz PHP działające pod nimi.
To wyjaśnia, dlaczego właściciel strony może mieć w panelu komunikat „Wszystko jest aktualne”, a mimo to potrzebować pilnej interwencji po stronie serwera. Aktualizacje WordPressa nie podmieniają samodzielnie zainstalowanego silnika PHP. Oficjalny komunikat WordPress.org z 21 października wprost wskazuje, że w związku z tymi lukami nie jest potrzebna ani planowana osobna aktualizacja samego CMS-a.
A co ze sklepami WooCommerce i danymi klientów?
Sklep WooCommerce działa na WordPressie, dlatego podlega tej samej zasadzie. Jeśli korzysta z podatnej wersji PHP, może być wystawiony na ryzyko niezależnie od tego, czy ma aktualne moduły płatności i motyw. W przypadku sklepu potencjalne konsekwencje są jednak szczególnie istotne biznesowo: przerwa w sprzedaży, naruszenie integralności zamówień albo ujawnienie informacji, do których ma dostęp przejęty proces serwera.
Czy hosting współdzielony jest bezpieczny? Kto odpowiada za poprawkę PHP?
W klasycznym hostingu współdzielonym aktualizacja PHP zwykle zależy od operatora usługi. Klient może mieć możliwość wyboru wersji PHP w panelu, ale nie oznacza to, że sam instaluje poprawki bezpieczeństwa dla serwera. Dostawca utrzymuje pakiety, konfigurację i procesy PHP. W przypadku VPS-a lub serwera dedykowanego odpowiedzialność zależy od umowy: przy usłudze niezarządzanej aktualizacje często należą do administratora klienta.
Warto więc rozróżnić zmianę głównej wersji PHP od zastosowania poprawki bezpieczeństwa. Przestawienie przełącznika z PHP 8.3 na 8.4 nie daje gwarancji, że nowa konfiguracja zawiera łatkę. Z drugiej strony dostawcy dystrybucji Linuksa mogą przenosić poprawki do własnych pakietów, zachowując starszy numer gałęzi. Ocena wyłącznie na podstawie widocznego numeru bywa wtedy niewystarczająca.
Dobrą praktyką jest poproszenie firmy hostingowej o jednoznaczne potwierdzenie, że środowisko obsługujące konkretną domenę zostało zabezpieczone przed CVE-2026-109618 i CVE-2026-109619. Warto zapytać, czy wdrożono nową wersję PHP lub poprawkę producenta pakietu, czy uruchomiono ponownie odpowiednie procesy i czy operator zaobserwował podejrzany ruch. Ogólne zapewnienie, że „serwery są chronione”, nie odpowiada jeszcze na wszystkie te pytania.
Które wersje PHP są bezpieczne po aktualizacji z 21 października 2026?
Twórcy PHP opublikowali poprawione wydania: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 oraz PHP 8.2.35. Są to wersje naprawiające obie opisane podatności w oficjalnie utrzymywanych gałęziach. CERT Polska wskazuje, że podatności dotyczą wydań od PHP 5.4, dlatego samo korzystanie z nowszej, lecz niezałatanej wersji nie zapewnia ochrony.
PHP 8.1 i starsze wydania nie otrzymują już standardowych aktualizacji bezpieczeństwa od projektu PHP. Niektóre firmy oferujące wydłużone wsparcie lub dostawcy systemów operacyjnych mogą dostarczać własne poprawki, ale trzeba to potwierdzić dla konkretnej instalacji. Osobnym zagadnieniem jest plan dalszej migracji: PHP 8.2 kończy oficjalne wsparcie bezpieczeństwa 31 grudnia 2026 roku.
Jak sprawdzić wersję PHP na stronie WordPress?
Najprostsza metoda prowadzi przez kokpit WordPressa. Wybierz Narzędzia → Stan witryny → Informacje → Serwer. Znajdziesz tam wersję PHP używaną przez stronę. Podobne informacje powinny być dostępne w panelu hostingu, często w sekcji dotyczącej ustawień PHP lub konfiguracji domeny.
Jeżeli widzisz numer starszy niż poprawione wydanie odpowiedniej gałęzi, należy pilnie ustalić z hostingodawcą status aktualizacji. Jeżeli serwer korzysta z PHP 7.4 albo 8.1, sam numer nie przesądza o braku poprawki dostawcy LTS, ale powinien uruchomić dodatkową weryfikację. W przypadku kilku stron lub subdomen nie zakładaj, że wszystkie korzystają z tej samej konfiguracji.
Co zrobić teraz, jeśli strona korzysta z podatnego PHP?
Przed zmianą głównej gałęzi PHP warto przygotować aktualną kopię bazy danych i plików oraz sprawdzić zgodność motywu, wtyczek i kodu indywidualnego. Po wdrożeniu należy przetestować formularze, panel administracyjny, wysyłkę wiadomości, logowanie i – jeśli to sklep – koszyk, płatności oraz obsługę zamówień. Kopia zapasowa jest zabezpieczeniem procesu aktualizacji, a nie rozwiązaniem samej podatności.
Jeśli natychmiastowe wdrożenie poprawki nie jest możliwe, brytyjskie NCSC zaleca ograniczenie ekspozycji, a w sytuacjach uzasadnionych ryzykiem także czasowe wyłączenie zagrożonego systemu. To decyzja wymagająca oceny konsekwencji dla firmy. Zabezpieczenie danych klientów jest ważniejsze niż utrzymywanie publicznego dostępu do niezabezpieczonej aplikacji za wszelką cenę.
Czy Wordfence, Cloudflare lub firewall zatrzymają PHP2Shell?
Wtyczki bezpieczeństwa i zapory aplikacyjne są przydatną dodatkową warstwą ochrony, ale nie usuwają podatnego kodu PHP. Szczególnie istotne jest to, że niektóre ścieżki ataku mogą zostać uruchomione na poziomie środowiska jeszcze przed wykonaniem właściwego kodu aplikacji. Samo zainstalowanie Wordfence, zmiana adresu logowania czy włączenie uwierzytelniania dwuskładnikowego nie rozwiązuje problemu.
Cloudflare poinformował, że przygotował i wdrożył reguły WAF służące do ograniczania prób wykorzystania PHP2Shell. To cenna ochrona przejściowa, zwłaszcza gdy dostawca hostingu nie zdążył jeszcze zaktualizować serwera. Nie daje ona jednak podstaw do odkładania poprawki. Oficjalny zespół PHP podkreśla, że tylko aktualizacja do wersji z usuniętym błędem stanowi pełne rozwiązanie.
Czy można rozpoznać, że ktoś już próbował zaatakować stronę?
Brak widocznych zmian na stronie nie oznacza, że do prób ataku nie doszło. Administrator powinien przejrzeć logi serwera WWW, błędy PHP i zdarzenia z WAF pod kątem nietypowych żądań, powtarzających się błędów pamięci, gwałtownego wzrostu odpowiedzi HTTP 500 oraz podejrzanych prób przesyłania formularzy lub plików. Są to jednak sygnały wymagające interpretacji, a nie samodzielny dowód skutecznego włamania.
W przypadku podejrzenia naruszenia bezpieczeństwa sama aktualizacja PHP może nie wystarczyć. Trzeba sprawdzić integralność plików, konta administratorów, nieznane zadania cykliczne, podejrzane skrypty oraz dostęp do bazy danych. Jeśli atakujący zdążył pozostawić mechanizm ponownego dostępu, nowa wersja PHP nie usunie go automatycznie. Należy również rozważyć rotację haseł i kluczy oraz zachować materiał potrzebny do analizy incydentu.
Dlaczego na świecie wyłączano strony internetowe? To nie była jedna globalna awaria
21 października media informowały o niedostępności części serwisów administracji publicznej w Europie. Niderlandzkie władze potwierdziły profilaktyczne wyłączenia związane z podatnościami PHP. Podobne działania podejmowano również w innych krajach. Nie oznacza to jednak, że cały internet przestał działać ani że każda niedostępna witryna padła ofiarą cyberataku.
Wiele wyłączeń było świadomą decyzją organizacji, które chciały ograniczyć ryzyko przed wprowadzeniem poprawki. ICANN poinformował, że tymczasowo wyłączył trzy serwisy administracyjne wykorzystujące PHP, jednocześnie podkreślając, że nie stwierdził negatywnego wpływu na swoje systemy. To ważne rozróżnienie: niedostępność nie jest równoznaczna z przełamaniem zabezpieczeń.
Ryzyko nie zatrzymuje się jednak na stronach rządowych. Dotyczy również szkół, szpitali, firm, sklepów i wszystkich innych usług korzystających z podatnego PHP. Według pomiaru W3Techs z 13 października 2026 roku PHP obsługiwało 69,7% stron, dla których udało się rozpoznać język po stronie serwera. Nie jest to równoznaczne z informacją, że 69,7% wszystkich stron zostało zhakowanych.
Czy strony na WordPress.com są zagrożone tak samo jak WordPress na własnym hostingu?
Nie należy utożsamiać WordPressa jako systemu CMS z usługą WordPress.com. Na własnym hostingu właściciel serwisu lub jego dostawca musi zadbać o stan środowiska PHP. Natomiast Automattic ogłosił 21 października, że chronione są serwisy utrzymywane na WordPress.com, WordPress VIP, WP Cloud i Pressable. Nie należy rozciągać tego komunikatu na każdą instalację WordPressa u dowolnego operatora.
Sztuczna inteligencja pomogła odkryć błędy obecne od lat
Wydarzenie jest przełomowe także z innego powodu. Wiz Research oraz niezależni badacze z Calif wykorzystali narzędzia AI do odnalezienia i analizy bardzo złożonych błędów, które przez wiele lat pozostawały w kodzie PHP. OpenAI opisał udział zespołów badawczych i dostawców infrastruktury w przygotowaniu poprawek przed publicznym ujawnieniem problemu.
Czy PHP2Shell może wpłynąć na SEO i widoczność strony w Google?
Sama informacja o istnieniu podatności PHP nie oznacza automatycznej kary od Google ani spadku pozycji każdej strony na WordPressie. Problem zaczyna się wtedy, gdy wystąpią realne skutki: długa niedostępność serwisu, przejęcie witryny, publikacja spamu, nieautoryzowane przekierowania albo utrata ważnych podstron. Takie zdarzenia mogą uderzyć zarówno w użytkowników, jak i w indeksację oraz reputację domeny.
Co właściciel strony powinien zapamiętać po 21 października 2026?
Najważniejszym działaniem jest potwierdzenie wdrożenia poprawki dla CVE-2026-109618 i CVE-2026-109619, a nie samo sprawdzenie, czy strona się wyświetla. Następnie należy ocenić logi, stan aplikacji oraz procedury aktualizacji na przyszłość. Regularne kopie zapasowe, monitoring i współpraca z odpowiedzialnym hostingodawcą mają sens wtedy, gdy towarzyszy im faktyczne usuwanie podatności.
Przy tworzeniu i rozwijaniu stron WordPress traktuje wybór hostingu, aktualizacje PHP, zgodność wtyczek i zabezpieczenia jako część jednej architektury serwisu. Dzisiejsze wydarzenia przypominają, dlaczego warto weryfikować ją nie tylko przy uruchomieniu strony, lecz przez cały okres jej działania.
Źródła techniczne i oficjalne komunikaty
Artykuł opracowano na podstawie komunikatów PHP Security Team, CERT Polska, WordPress.org, Wiz Research, Cloudflare oraz NCSC.
Stan informacji: 21 października 2026 roku.
