PHP2Shell: co muszą teraz zrobić właściciele stron WordPress

PHP2Shell to para krytycznych podatności w samym PHP, ujawniona 21 października 2026 r. i oceniona na 9,2 w skali CVSS. W niezałatanym środowisku PHP atakujący bez konta może wykonać kod na serwerze albo odczytać pamięć, w której znajdują się hasła, tokeny sesji i klucze API. Badacze zademonstrowali atak na aktualnych instalacjach WordPressa. Aktualizacja WordPressa, motywu czy wtyczek nie rozwiązuje problemu: zaktualizować trzeba wersję PHP, na której działa strona.

Ten poradnik wyjaśnia, czym jest PHP2Shell, jak sprawdzić, czy strona jest zagrożona, o co zapytać dostawcę hostingu i co zrobić, jeśli aktualizacja nie jest możliwa jeszcze dziś.

Czym jest PHP2Shell

Badanie przeprowadzone przez Wiz Research, OpenAI Codex Security i Calif wykazało dwie powiązane klasy błędów bezpieczeństwa pamięci w silniku PHP:

• CVE-2026-109618, uszkodzenie stanu przy braku pamięci. Sposób, w jaki PHP obsługuje wyczerpanie pamięci, może uszkodzić jego stan. Atakujący może to wykorzystać do wykonania kodu jako proces roboczy (worker) PHP, bez logowania.
• CVE-2026-109619, nieaktualny stan globalny między żądaniami. Dane z jednego żądania mogą przetrwać do następnego. Prowadzi to do błędu use-after-free, który może ujawnić pamięć procesu roboczego lub umożliwić wykonanie kodu.

Ponieważ luka tkwi w PHP, własny kod strony nie musi zawierać żadnego błędu. Według badaczy narażona może być nawet strona „Hello World” działająca na podatnej wersji PHP. WordPress, Drupal i Joomla były po prostu aplikacjami, na których badacze zademonstrowali zdalne wykonanie kodu bez uwierzytelnienia. Zespół PHP wydał poprawione wersje tego samego dnia.

Dla strony na WordPressie najważniejsze są dwie konsekwencje:

1. Przejęcie serwera. Wykonanie kodu jako proces roboczy PHP zwykle oznacza, że atakujący może zmieniać pliki, dodać administratora, podrzucić tylną furtkę albo dostać się do bazy danych.
2. Cicha kradzież danych. Odczyt pamięci działa bez uruchamiania złośliwego kodu, więc może zostawić niewiele śladów. Pamięć mocno obciążonego procesu roboczego PHP może zawierać hasła i ciasteczka innych odwiedzających, hasło do bazy danych i klucze API.

Czy moja strona jest zagrożona?

Niemal na pewno, chyba że PHP zostało zaktualizowane 21 października 2026 r. lub później. Badacze znaleźli podatne wydania sięgające aż PHP 5.4. Oto pierwsze poprawione wydania w każdej wspieranej gałęzi:

PHP 8.1, 8.0 i wszystkie wersje 7.x nie są już wspierane przez projekt PHP i nie ma ich w tej tabeli. Jeśli strona działa na jednej z nich, nie istnieje poprawione wydanie do zainstalowania: trzeba przejść na wspieraną gałąź.

Dokładną wersję można sprawdzić w WordPressie: wystarczy otworzyć Narzędzia → Kondycja witryny → Informacje i rozwinąć sekcję Serwer. Wiersz „Wersja PHP” pokazuje pełny numer, na przykład 8.3.36. Dwie pierwsze części (8.3) to za mało: liczy się ostatnia liczba.

Jak usunąć zagrożenie

Jedynym pełnym rozwiązaniem jest załatane środowisko PHP, a po nim restart.

1. Zaktualizować PHP w każdym środowisku. Na własnym serwerze należy zainstalować zaktualizowane pakiety z dystrybucji, gdy tylko zostaną opublikowane, albo oficjalne wydanie z php.net. Na hostingu zarządzanym lub współdzielonym PHP aktualizuje dostawca; warto zapytać go wprost, czy Państwa pakiet działa już na poprawionym wydaniu.
2. Zrestartować PHP. Nowy pakiet PHP nic nie daje, dopóki działające procesy nie zostaną zastąpione. Trzeba zrestartować PHP-FPM, Apache z mod_php i wszystkie długo działające procesy robocze PHP.
3. Sprawdzić efekt. Ponownie zajrzeć do Kondycji witryny. Wersja PHP musi teraz być równa poprawionemu wydaniu dla danej gałęzi lub od niego wyższa.
4. Nie zapomnieć o pozostałych środowiskach. Liczą się też strony testowe (staging), druga wersja PHP wybrana w panelu hostingu, PHP używane przez zadania cron i WP-CLI oraz obrazy kontenerów.

Jeśli panel hostingu ma przełącznik wersji PHP, wybór „8.3” lub „8.4” jest bezpieczny tylko wtedy, gdy dostawca zainstalował już pod tą etykietą załataną kompilację. Prawdę pokazuje Kondycja witryny.

Jeśli aktualizacja dziś nie jest możliwa

Badacze wymieniają środki tymczasowe. Każdy blokuje część ścieżek ataku, żaden nie blokuje wszystkich, a niektóre mogą wpłynąć na działanie strony, dlatego najpierw warto je przetestować:

• fatal_error_backtraces = 0, o ile dana wersja PHP to obsługuje.
• Obniżyć post_max_size i max_input_nesting_level na tyle, na ile pozwalają formularze i przesyłanie plików, oraz ustawić session.upload_progress.enabled = 0, jeśli nic nie korzysta ze śledzenia postępu przesyłania.
• Częściej odnawiać procesy robocze PHP-FPM, ustawiając niższe pm.max_requests (kosztem wydajności).
• memory_limit = -1 usuwa ścieżkę przez limit pamięci, na której opierają się niektóre ataki, ale przerzuca wyczerpanie pamięci na system operacyjny. Można go używać tylko razem z limitem na poziomie systemu operacyjnego, takim jak memory.max w cgroup v2, i nigdy nie zastępować go przez RLIMIT_AS ani RLIMIT_DATA, które według komunikatu bezpieczeństwa PHP mogą wywołać ten sam błąd.

Ukrywanie błędów PHP (display_errors, error_reporting lub @) nie należy do tych środków: projekt PHP podkreśla, że to nie pomaga.

Dostawcy zapór sieciowych i CDN opublikowali reguły dla PHP2Shell. Mogą one zmniejszyć ryzyko, ale badacze jasno mówią, że reguła ochronna nie zastępuje aktualizacji PHP.

Na jakie oznaki zwracać uwagę

Żaden pojedynczy wpis w logach nie dowodzi ataku. Badacze wskazują sygnały, które warto zbadać: nietypowo duże lub zniekształcone ciasteczka PHPSESSID w odpowiedziach, dziwne żądania multipart, po których pojawiają się błędy limitu pamięci lub serie odpowiedzi HTTP 500, oraz procesy robocze PHP, które bez powodu się zawieszają albo restartują. Brak tych sygnałów nie dowodzi, że strona jest czysta, bo odczyt pamięci może nie zostawić żadnych śladów w logach WordPressa.

Jeśli zauważą Państwo te oznaki, należy potraktować sytuację jako możliwy incydent. Nasz poradnik o oznakach zhakowanej strony WordPress pomoże przy pierwszych kontrolach. Ponieważ wykradziona pamięć może zawierać sekrety, po załataniu trzeba zmienić hasło do bazy danych, klucze i sole w wp-config.php oraz wszystkie klucze API. Jeśli mogło dojść do ujawnienia danych osobowych, zaczyna biec termin wynikający z RODO: zob. nasz poradnik o zgłaszaniu naruszeń w ciągu 72 godzin.

Od czego zacząć

1. Otworzyć Narzędzia → Kondycja witryny → Informacje → Serwer i zapisać dokładną wersję PHP każdej prowadzonej strony.
2. Porównać ją z tabelą powyżej. Wszystko poniżej poprawionego wydania albo na PHP 8.1 i starszym wymaga działania jeszcze dziś.
3. Zaktualizować PHP lub poprosić dostawcę hostingu o załatane wydanie, a potem upewnić się, że PHP-FPM lub Apache został zrestartowany.
4. Ponownie sprawdzić Kondycję witryny i zachować zrzut ekranu jako dowód poprawki.
5. Przejrzeć logi pod kątem opisanych wyżej oznak i wymienić sekrety, jeśli coś wygląda podejrzanie.

Źródła: php2shell.com, komunikat PHP Foundation, Wiz Research.