PHP2Shell: jak zareagowaliśmy na krytyczną lukę w PHP. Oś czasu i checklista

PHP2Shell to dwie luki w samym PHP, czyli w silniku pod WordPressem, PrestaShopem i tysiącami firmowych aplikacji. Pozwalają uruchomić na serwerze obcy kod jednym zapytaniem z internetu, bez logowania. Szczegóły wyciekły dzień przed poprawkami.

Przegląd logów i plików od 20 października nie pokazał śladów włamania.

Opisujemy trzy dni pracy naszego zespołu, od blokady ruchu w dniu publikacji poprawek po przeniesienie firmowego panelu klienta na PHP 8.3.36. Na końcu znajdziesz checklistę dla właściciela strony i odpowiedzi na pytania, które dostawaliśmy w tych dniach.

Co się stało 21 października

20 października zespół PHP zapowiedział na następny dzień wydanie z poprawkami dwóch krytycznych luk. Obie dostały ocenę 9,2 na 10 w skali CVSS. Krytyczne są w niej oceny od 9,0. Tego samego dnia szczegóły wyciekły do sieci, przed planowaną publikacją.

21 października o 14:00 UTC, czyli o 16:00 czasu polskiego, ukazały się poprawione wersje:

• PHP 8.5.12,
• PHP 8.4.27,
• PHP 8.3.36,
• PHP 8.2.35.

Luki mają numery CVE-2026-109618 i CVE-2026-109619. Opis, listę wersji i zalecenia opublikował zespół PHP w komunikacie na php.net. Tego samego dnia CERT Polska wydał komunikat z zaleceniami dla administratorów.

Ataki zaczęły się przed poprawkami.

Cloudflare pisał, że widział ruch atakujący swoich klientów jeszcze przed oficjalną publikacją. Amazon podał później, że pierwsze próby zarejestrował już 17 października.

My dowiedzieliśmy się o sprawie z komunikatów PHP i CERT Polska oraz z biuletynów branżowych, między innymi od dostawców wtyczek do WordPressa. Potem zaczęli pisać klienci.

Dlaczego to groźne

Atakujący nie potrzebuje hasła ani konta. Wysyła jedno spreparowane zapytanie i uruchamia na serwerze własny kod. Zespół PHP podaje, że przy Apache z mod_php atak działa, zanim wykona się jakikolwiek kod strony. Wtyczka bezpieczeństwa w WordPressie nie ma wtedy kiedy zareagować.

21 października spisaliśmy ocenę ryzyka dla zarządu jednego z klientów. Wymieniliśmy w niej cztery grupy skutków:

• wyciek danych: bazy klientów oraz hasła i dane dostępowe zapisane w konfiguracji strony;
• przejęcie strony: podmiana treści, przekierowania na oszustwa, skrypty kradnące dane kart płatniczych;
• wykorzystanie serwera: wysyłka spamu, kopanie kryptowalut, ataki na kolejne systemy;
• straty w firmie: przestój, koszty sprzątania, utrata zaufania klientów.

Przekierowania i spam na przejętej stronie kończą się też ostrzeżeniami w Google i spadkiem pozycji w wynikach wyszukiwania.

Jest też RODO. Jeśli ktoś wyniesie dane osobowe, administrator ma 72 godziny od stwierdzenia naruszenia na zgłoszenie go do UODO. To godziny zegarowe, liczone także w weekend.

Ataki na takie luki są masowe i zautomatyzowane. Boty sprawdzają po kolei każdy serwer z PHP, który odpowiada w internecie. Mała strona firmowa jest dla nich tak samo dobrym celem jak duży sklep. Najbardziej narażone są strony na PHP 8.1 i starszym.

Kogo dotyczy

Każdej strony i aplikacji, która działa na PHP. Według W3Techs to 69,3% stron, dla których da się rozpoznać język serwera.

Na liście jest WordPress z WooCommerce, PrestaShop, Joomla, aplikacje na Symfony i Laravelu oraz systemy pisane od zera. Sposób uruchomienia PHP nie ma znaczenia. Zespół PHP wymienia PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed.

Aktualizacja WordPressa ani wtyczek tej luki nie zamyka.

Błąd siedzi w PHP, czyli w programie, który wykonuje kod strony. Poprawić go może tylko ten, kto zarządza serwerem: Ty, Twój hosting albo firma, która opiekuje się stroną.

Najgorzej mają stare wersje

CERT Polska podaje, że podatne są wszystkie wersje PHP od 5.4 wzwyż. Gotowe wydania z poprawką dostały tylko wersje 8.2–8.5.

PHP 7.4, 8.0 i 8.1 nie dostają już poprawek od zespołu PHP. 21 października zespół udostępnił dla nich wyłącznie łatki w kodzie źródłowym, bez gotowych paczek. Hosting musi sam przebudować z nich PHP. Plesk zrobił to dla swoich wersji 7.4, 8.0 i 8.1 jeszcze 21 października wieczorem. Inni dostawcy działali we własnym tempie.

Tu jest pułapka. Przebudowane PHP 7.4 ma ten sam numer wersji co przed poprawką. Zmienia się tylko data kompilacji. Sam numer nie powie Ci więc, czy stara wersja jest załatana.

Oś czasu: jak zareagowaliśmy

Godziny pochodzą z maili i zadań w naszym CRM, bez nazw klientów.

21 października, środa

• Wczesne popołudnie. Zanim pojawiły się poprawki, zablokowaliśmy ruch do firmowych serwerów jednego z klientów. Od tej chwili serwery przyjmowały ruch tylko z dozwolonych adresów IP. Blokada objęła też serwisy automatyzacji.
• 15:59. Potwierdziliśmy klientowi, że blokada działa, a z dozwolonych adresów wszystko jest dostępne.
• Po publikacji poprawek. Na serwerach z PHP 8.2 i nowszym zaktualizowaliśmy PHP przez Plesk do wersji z poprawką i zrestartowaliśmy usługi.
• 17:11. Wysłaliśmy zarządowi klienta pisemną ocenę ryzyka. Prostym językiem: co grozi, co dają nasze warstwy ochrony, jaki mamy plan i o jaką decyzję prosimy.
• 18:24. Pierwszy klient zapytał przez panel klienta o poprawkę.
• 18:34. Plesk zapowiedział przebudowę PHP 7.4, 8.0 i 8.1 z łatkami, bez terminu. Przekazaliśmy to klientowi.
• 21:02–21:05. Założyliśmy w CRM 11 zadań kontrolnych, po jednym dla każdej osoby, która prowadzi strony klientów. Priorytet pilny, termin na następny dzień.
• 22:48. Napisaliśmy do klienta e-commerce, którego sklep działa na PHP 7.4 u zewnętrznego hostingu. Ten przypadek opisujemy w następnej sekcji.
• 22:52. Plesk wydał załatane PHP dla starszych wersji. Zaktualizowaliśmy je i poprosiliśmy klienta z blokadą o zgodę na jej zdjęcie.
• Do 23:07. Zamknęliśmy 2 zgłoszenia klientów z pytaniem o poprawkę i część zadań kontrolnych.

22 października, czwartek

• Do 05:12. Zewnętrzny hosting innego klienta skończył aktualizację PHP na wszystkich serwerach. Sprawdziliśmy to u dostawcy i na samym serwerze. Wszystkie wersje PHP były przebudowane 21 października.
• 12:45. Napisaliśmy do tego klienta, że jego 11 serwisów jest zabezpieczonych, w tym serwis B2B i wersje testowe. Klient nie musiał nic robić.
• W ciągu dnia. Kolejne osoby zamykały przeglądy swoich stron. Osobno sprawdziliśmy serwisy klientów, którzy sami przysłali nam komunikat CERT Polska.

23 października, piątek

• Panel na PHP 8.3.36. Firmowy panel jednego z klientów działał na starszym PHP. Przenieśliśmy go na PHP 8.3.36 bez przerwy w pracy. Nasz programista backendu rozszerzył warstwę zgodności, którą aplikacja już miała. Przetestował zmianę lokalnie i wdrożył ją na serwer. Pełne dostosowanie kodu do nowego PHP robimy jako osobną pracę.
• Zgoda na migrację sklepu. Klient e-commerce zgodził się na przyspieszoną migrację: wersja testowa na PHP 8.4, pełne testy, poprawki, potem produkcja. Prace trwają.
• 10:23. Zamknięte 9 z 11 zadań kontrolnych. Jedno okazało się bezprzedmiotowe, jedno było jeszcze otwarte.

Jedną rzecz chcemy zrobić lepiej. Pierwsze pytanie od klienta przyszło o 18:24, a maile do pozostałych klientów zaczęliśmy wysyłać dopiero wieczorem. Następnym razem klient ma dostać od nas informację, zanim zdąży zapytać.

Dlaczego nie przełączyliśmy sklepu na nowe PHP „na ślepo”

Najtrudniejszy był sklep internetowy na PHP 7.4 u zewnętrznego hostingu. PHP na tym serwerze aktualizuje sam hosting. My możemy pytać i sprawdzać. 21 października hosting zrobił dwie rzeczy:

• wyłączył ustawienie PHP, przez które działała jedna z luk;
• zaktualizował PHP 8.3, na którym działały inne serwisy tego klienta.

Wyłączone ustawienie utrudnia atak, ale go nie wyklucza. Sprawdziliśmy na serwerze, co dokładnie hosting zmienił, i zapytaliśmy o łatkę do PHP 7.4.

Najprostsze wyjście kusiło. Przełączyć sklep w panelu hostingu na PHP 8.4 i mieć spokój. Zanim to zrobiliśmy, uruchomiliśmy kopię sklepu na PHP 8.4 i przeklikaliśmy front oraz panel administracyjny.

Większość działała, ale wyszły dwa problemy:

• 3 funkcje panelu administracyjnego nie działały;
• strona główna przestałaby się ładować przy każdej awarii zewnętrznego serwisu z opiniami klientów.

Płatności, etykiet kurierskich i importów nie przetestowaliśmy. Te funkcje rozmawiają z prawdziwymi systemami. Sklep nie miał bezpiecznego środowiska testowego. Testowe zamówienie na kopii mogłoby trafić do prawdziwego operatora płatności albo kuriera.

Przełączenie produkcji dałoby więc taki wynik: luka zamknięta, część panelu nie działa, a o płatnościach nic nie wiemy. Dla sklepu, który żyje z zamówień, to też jest awaria.

Dlatego produkcja zostaje na razie na PHP 7.4, a nowe PHP sprawdzamy na kopii.

Klientowi opisaliśmy wynik testu i zaproponowaliśmy przyspieszoną migrację z pełnym testem na kopii, na którą zgodził się 23 października.

Cloudflare i ochrona serwera: co dają, a czego nie

Część stron naszych klientów działa za Cloudflare w planie darmowym. Serwery chroni też BitNinja. W ocenie ryzyka z 21 października napisaliśmy o tych warstwach tak:

• kupują czas i odcinają część ataków;
• nie łatają luki w PHP;
• Cloudflare nie pomoże, gdy atak idzie prosto na adres IP serwera;
• żadne z tych narzędzi nie dawało pewności, że jego reguły łapią każdy wariant ataku.

Cloudflare opisał na swoim blogu reguły przeciw PHP2Shell, aktywne od 3:02 UTC 21 października, także w planie darmowym. W tym samym tekście przyznał, że atakujący zmieniali zapytania, żeby ominąć reguły. I że PHP trzeba załatać mimo ochrony WAF.

Przy systemach wewnętrznych najszybciej zadziałało coś prostszego. Lista dozwolonych adresów IP. Firmowy panel nie musi być otwarty dla całego internetu. Jeśli serwer przyjmuje połączenia tylko z biura i kilku znanych usług, bot z drugiego końca świata w ogóle do niego nie dotrze. Dla sklepu takiej blokady nie ustawisz, bo klienci przychodzą z każdego adresu.

Trzecia warstwa to ustawienia PHP. CERT Polska podał zmiany w php.ini na czas do aktualizacji: memory_limit, post_max_size, max_input_vars i session.upload_progress.enabled. CERT sam zaznacza, że nie wykluczają one ataku.

Pełną ochronę daje tylko PHP z poprawką. Blokada adresów IP dała nam czas do 22:52, kiedy Plesk wydał załatane starsze wersje PHP.

Co zmieniamy na stałe

Po tych trzech dniach wprowadziliśmy cztery zmiany.

Procedura „krytyczna luka” z terminem 24 godzin

Każda osoba, która prowadzi strony klientów, dostaje w CRM zadanie z tabelą wersji i dwoma szablonami maili. Ma 24 godziny na sprawdzenie stron i wysłanie maili. Kroki są takie:

1. Sprawdź wersję PHP każdej strony pod opieką.
2. Porównaj ją z tabelą wersji z poprawką.
3. Strona załatana: napisz klientowi, że była luka i PHP jest już zaktualizowane.
4. Strona podatna: opisz klientowi dwie drogi. Może poczekać na poprawkę i przyjąć ryzyko albo podnieść wersję PHP lub systemu strony. Decyduje klient.
5. Napisz do klientów z umową opieki i do właścicieli dużych serwisów.

Każdy mail odpowiada na trzy pytania: co się stało, co zrobiliśmy i czy klient musi coś zrobić.

Czas na sprawdzenie i maile rozliczamy z abonamentu opieki.

Wycofujemy PHP 8.2 i starsze

PHP 8.2 dostaje poprawki bezpieczeństwa do 31 grudnia 2026 r. Tak wynika z harmonogramu wersji na php.net. Potem znajdzie się tam, gdzie dziś jest PHP 7.4. Przy następnej luce zespół PHP nie będzie musiał wydać dla niego poprawki.

Docelowo wszystkie strony pod naszą opieką mają działać na PHP 8.3 lub nowszym. PHP 8.3 dostaje poprawki do końca 2027 r., a PHP 8.4 do końca 2028 r. Kto migruje teraz, na 8.4 zyskuje rok poprawek więcej.

Migracja PHP zawsze najpierw na kopii

Nową wersję PHP uruchamiamy najpierw na kopii strony. Na niej testujemy ścieżki, które zarabiają: zamówienie, płatność, panel administracyjny. Sklep z integracjami potrzebuje środowiska testowego z odciętymi płatnościami i kurierami. Przy sklepie na PHP 7.4 brak takiego środowiska zatrzymał nam testy płatności, etykiet i importów.

Warstwy ochrony to bufor

Cloudflare, ochrona serwera i lista dozwolonych adresów IP zostają, bo dają czas na aktualizację PHP. Przy systemach wewnętrznych lista adresów IP działa od razu, jeszcze zanim pojawi się poprawka.

Checklista dla właściciela strony

Siedem rzeczy, które możesz sprawdzić dziś.

1. Sprawdź wersję PHP. Bezpieczne wydania to 8.2.35, 8.3.36, 8.4.27 i 8.5.12 lub nowsze. PHP 8.1 i starsze to realne ryzyko. Przy nich sprawdź datę przebudowy, bo numer wersji się nie zmienia.
2. Nie licz na aktualizację WordPressa. Nowa wersja WordPressa, PrestaShopa czy wtyczek nie łata PHP.
3. Zapytaj hosting, czy i kiedy wgrał poprawkę. Poproś o datę i wersję.
4. Zaplanuj migrację PHP z wyprzedzeniem. Na PHP 8.2 lub starszym zaplanuj przejście na 8.3 albo 8.4 przed 31 grudnia 2026 r.
5. Nie traktuj WAF jak łatki. Cloudflare i ochrona serwera pomagają, ale nie zastępują aktualizacji.
6. Miej środowisko testowe. Na kopii strony z odciętymi płatnościami i kurierami przetestujesz nowe PHP bez ryzyka dla zamówień.
7. Zapamiętaj 72 godziny. Tyle masz na zgłoszenie do UODO, jeśli dojdzie do naruszenia danych osobowych.

Szerszą listę dla sklepów opisaliśmy w artykule Checklista bezpieczeństwa sklepu internetowego 2026.

Najczęstsze pytania

Czy aktualizacja WordPressa wystarczy?

Nie. Luka siedzi w PHP. Aktualizacje WordPressa i wtyczek są potrzebne z innych powodów, ale PHP2Shell nie zamykają. Poprawkę musi wgrać hosting albo administrator serwera.

Jak sprawdzić wersję PHP?

W WordPressie wejdź w Narzędzia → Zdrowie witryny → Informacje i rozwiń sekcję Serwer. W PrestaShopie wersję PHP pokazuje strona Zaawansowane → Informacje. W Plesku znajdziesz ją w ustawieniach PHP domeny.

Polecenie php -v w konsoli serwera pokazuje wersję i datę kompilacji. Uwaga: to wersja PHP z wiersza poleceń. Strona może działać na innej.

Czy Cloudflare mnie chroni?

Częściowo. Cloudflare wdrożył reguły przeciw PHP2Shell 21 października, także w planie darmowym. Chroni jednak tylko ruch, który przez niego przechodzi. Jeśli serwer przyjmuje ruch spoza Cloudflare, atak może pójść prosto na jego adres IP. Sam Cloudflare zaleca aktualizację PHP mimo swoich reguł.

Co jeśli mam PHP 7.4?

Na teraz: zapytaj hosting, czy przebudował PHP 7.4 z łatką z 21 października, i poproś o datę kompilacji.

Na stałe: migracja na PHP 8.3 albo 8.4, najpierw na kopii strony. PHP 7.4 nie dostaje oficjalnych poprawek od listopada 2022 r. Tym razem zespół PHP przygotował łatkę w kodzie źródłowym. Następnym razem może jej nie być.

Czy muszę zgłaszać do UODO?

Sama luka nie jest naruszeniem. Zgłoszenie jest potrzebne, gdy ktoś dostał się do danych osobowych i może to zaszkodzić osobom, których te dane dotyczą. Masz na to 72 godziny od stwierdzenia naruszenia, zgodnie z art. 33 RODO. Nie wiesz, czy doszło do włamania? Zleć przegląd logów i plików, zanim ten czas minie.

Podsumowanie

Od wycieku szczegółów do poprawek minął jeden dzień. Ataki ruszyły jeszcze wcześniej. W takim tempie nie ma czasu na ustalanie, kto co sprawdza. Dlatego mamy to teraz spisane w CRM: zadania dla każdej osoby, tabelę wersji i dwa szablony maili.

Nie wiesz, na jakim PHP działa Twoja strona, albo hosting milczy w sprawie poprawki? Napisz do nas, podaj adres strony, a odpiszemy, od czego zacząć. Stałą opiekę nad stronami i aplikacjami opisujemy na stronie opieka programistyczna i outsourcing IT. Strony na WordPressie mają osobną ofertę: opieka nad WordPressem.