PHP2Shell bez żargonu: co się stało i co to znaczy dla Ciebie

22 października 2026

21 października 2026 roku w radiu i telewizji mówiono o wyłączonych stronach urzędów, części Wikipedii i serwisach rządowych w kilku krajach Europy. Powodem były dwie luki w PHP. Jeśli masz stronę internetową albo sklep, ta historia dotyczy Ciebie bardziej, niż mogłoby się wydawać. Wyjaśniamy bez technicznego żargonu, co się stało i dlaczego to był wyjątkowy dzień.

Szukasz konkretnych kroków do wykonania? Są w naszym poradniku Krytyczna luka w PHP: co zrobić na hostingu współdzielonym, zanim dostaniesz łatkę.

Czym jest PHP i dlaczego prawie na pewno go używasz

Wyobraź sobie restaurację. To, co widzi gość, czyli sala, menu i talerz na stole, to Twoja strona internetowa. Ale każde danie powstaje w kuchni, do której gość nie zagląda. PHP to właśnie taka kuchnia. Kiedy ktoś otwiera Twoją stronę, serwer uruchamia PHP, a ono pobiera treści z bazy danych, składa z nich stronę i wysyła ją do przeglądarki.

Na PHP działa WordPress, a więc i WooCommerce, Joomla i wiele systemów sklepowych. Według danych cytowanych przez media korzysta z niego blisko 70% stron internetowych na świecie. Jeśli Twoja strona powstała na WordPressie, działa na PHP, nawet jeśli nigdy nie słyszałeś tej nazwy.

Ważne: PHP nie jest częścią Twojej strony, którą widzisz w panelu WordPressa. Instaluje i aktualizuje go firma hostingowa, na serwerze, na którym strona stoi. Do tego wrócimy, bo to klucz do zrozumienia całej sytuacji.

Co się stało 21 października

Zespół rozwijający PHP wydał awaryjne poprawki dla dwóch luk oznaczonych jako CVE-2026-109618 i CVE-2026-109619. Każda dostała ocenę 9.2 na 10 w skali CVSS, czyli najwyższy poziom: krytyczny. Media branżowe nazwały je wspólnie PHP2Shell.

Ciekawostka: przy wykrywaniu jednej z nich pomógł model sztucznej inteligencji, a całość koordynowali badacze bezpieczeństwa przez około dwa miesiące. AI coraz częściej znajduje błędy, które przez lata umykały ludziom. To dobra wiadomość dla obrońców, ale te same narzędzia mają też atakujący.

Dlaczego te luki są tak groźne

Luki w oprogramowaniu wykrywa się codziennie. Większość wymaga spełnienia jakichś warunków: zalogowania się, konkretnej wtyczki, nietypowej konfiguracji. Ta była inna z kilku powodów naraz.

Nie trzeba się logować. Wystarczy wysłać do strony odpowiednio przygotowane zapytanie, takie samo jak przy zwykłym otwieraniu strony.
Atak działa, zanim ruszy Twoja strona. Błąd siedzi w samym PHP, więc zabezpieczenia WordPressa, wtyczki bezpieczeństwa i silne hasła nie mają tu nic do powiedzenia.
Atakujący przejmuje serwer. Może uruchamiać własne polecenia: podmienić stronę, wykraść bazę klientów, podpiąć złośliwy kod do koszyka albo użyć serwera do dalszych ataków.
Dotyczy praktycznie każdej używanej wersji PHP. Nie chodzi o niszową konfigurację, tylko o miliony serwerów naraz.
Szczegóły wyciekły przed publikacją. Poprawki miały wyjść później, ale przyspieszono je, bo informacje o lukach były już w obiegu.

I najważniejsze: ataki już trwają. Amazon zarejestrował pierwszą próbę cztery dni przed oficjalnym ogłoszeniem. Po publikacji poprawek próby ruszyły w ciągu godzin, z wielu adresów naraz. Firma Pantheon zablokowała ponad 60 tysięcy podejrzanych zapytań, a Cloudflare widział, jak atakujący zmieniają metody, żeby ominąć zabezpieczenia. CrowdStrike zwraca uwagę na jeszcze jedną rzecz: takie ataki zostawiają bardzo mało śladów w standardowych logach.

Dlaczego rządy wyłączały strony

Kiedy wiadomo, że luka jest łatwa do wykorzystania, a ataki już się zaczęły, wyłączenie strony bywa najrozsądniejszą decyzją. Lepiej, żeby serwis nie działał przez kilka godzin, niż żeby ktoś przejął go na tygodnie.

Tak postąpiło wiele instytucji. W Polsce Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w systemie SSDIP. Ministerstwo Cyfryzacji podkreśla, że nie dotyczy to wszystkich BIP-ów w kraju. Za granicą wyłączano m.in. serwisy rządowe w Holandii, Finlandii, Francji i Wielkiej Brytanii, a Fundacja Wikimedia zapobiegawczo wyłączyła część swoich systemów do czasu instalacji poprawek.

Dla właściciela strony to ważna lekcja. Instytucje z całymi działami IT uznały, że chwilowe wyłączenie to rozsądna cena za bezpieczeństwo. Jeśli Twoja strona przetwarza dane klientów, taka decyzja nie jest przesadą.

Kto odpowiada za co na Twojej stronie

W tej historii łatwo pogubić się w odpowiedzialności. Na typowym hostingu współdzielonym wygląda to tak:

Element	Kto aktualizuje	Co to znaczy w tej sytuacji
PHP na serwerze	Firma hostingowa	Poprawkę wgrywa hosting. Ty możesz tylko sprawdzić, czy już to zrobił, i chronić stronę w międzyczasie.
Wersja PHP wybrana dla strony	Ty lub Twój opiekun strony	Jeśli strona działa na bardzo starej wersji, np. 7.4, łatki mogą do niej nie trafić wcale. Wtedy trzeba przejść na nowszą.
WordPress, motyw, wtyczki	Ty lub Twój opiekun strony	Tym razem nie one są problemem, ale stara strona utrudnia przejście na nowe PHP.
Kopie zapasowe i kontrola po incydencie	Ty lub Twój opiekun strony	Gdyby coś poszło nie tak, czysta kopia sprzed ataku to jedyny pewny punkt powrotu.

21 października pokazał też, że polscy hostingodawcy działali w różnym tempie. Jedni ogłaszali zakończenie wdrożenia jeszcze tego samego popołudnia, inni kończyli w nocy. Tego nie kontrolujesz, ale możesz wiedzieć, na jakim etapie jest Twój serwer. Trzeba tylko wiedzieć, gdzie i jak to sprawdzić.

Trzy pytania, które warto sobie zadać

Czy wiem, na jakiej wersji PHP działa moja strona? Jeśli nie, to znak, że nikt tego nie pilnuje.
Czy 21 października wiedziałbym, co zrobić? Kto miał zdecydować o wyłączeniu sklepu, kto miał sprawdzić, czy hosting już załatał serwer?
Czy mam kopię strony, której mogę zaufać? Aktualną, sprawdzoną i trzymaną poza serwerem, na którym stoi strona.

Jeśli na któreś pytanie odpowiedź brzmi „nie wiem”, to normalne. Większość właścicieli stron zajmuje się swoim biznesem, a nie śledzeniem komunikatów bezpieczeństwa. Właśnie dlatego taka praca powinna należeć do kogoś, kto robi to na co dzień.

Nie chcesz pilnować tego sam? W ramach opieki nad stroną śledzimy komunikaty bezpieczeństwa, sprawdzamy wersję PHP i aktualizacje, robimy kopie zapasowe i reagujemy, kiedy dzieje się coś takiego jak 21 października. Ty dostajesz informację, co zrobiliśmy, zamiast szukać jej w nocnych wiadomościach.

Co dalej

Dla większości stron na dobrym hostingu ta historia skończy się na tym, że hostingodawca wgrał poprawki, a właściciel nawet tego nie zauważył. Ale to nie była ostatnia taka sytuacja. Narzędzia AI przyspieszają wykrywanie błędów i po stronie obrońców, i atakujących, więc takich dni będzie raczej więcej niż mniej. Warto mieć plan, zanim przyjdzie następny.

Jeśli Twoja strona jeszcze nie ma łatki albo chcesz sprawdzić, czy wszystko jest w porządku, przejdź do praktycznego poradnika.