PHP2Shell: krytyczne luki w PHP i co musi zrobić właściciel strony

Co się stało

21 października 2026 r. zespół PHP wydał awaryjne poprawki dla dwóch krytycznych luk, nazwanych wspólnie PHP2Shell: CVE-2026-109618 i CVE-2026-109619. Obie oceniono na 9,2 w skali CVSS 4.0 i obie pozwalają na zdalne wykonanie kodu na serwerze bez logowania – wystarczy odpowiednio spreparowane żądanie HTTP.

Najważniejsze jest to, że błąd tkwi w samym interpreterze PHP, a nie w konkretnym CMS-ie, wtyczce czy szablonie. Atak działa, zanim w ogóle uruchomi się kod Twojej strony. Dlatego dotyczy praktycznie wszystkiego, co działa na PHP: WordPressa, WooCommerce, PrestaShopa, Magento, Laravela i autorskich systemów.

Sprawa szybko przestała być teoretyczna. Według danych AWS przytaczanych przez Datadog pierwsze próby ataków odnotowano już 17 października – cztery dni przed publikacją poprawek. 26 października amerykańska agencja CISA wpisała obie luki do katalogu podatności aktywnie wykorzystywanych w atakach (KEV). Firmy bezpieczeństwa raportują masowe, nieukierunkowane skanowanie internetu w poszukiwaniu niezałatanych serwerów.

Na czym polegają luki

Bez wchodzenia w szczegóły techniczne:

• CVE-2026-109618 – gdy PHP zabraknie pamięci w trakcie przygotowywania danych żądania, proces sprzątania może potraktować niedokończone, kontrolowane przez atakującego dane jako poprawne. W efekcie atakujący może doprowadzić do uruchomienia dowolnego polecenia systemowego.
• CVE-2026-109619 – wewnętrzny stan należący do jednego żądania może „przeżyć” zwolnienie pamięci i zostać użyty przez kolejne żądanie obsługiwane przez ten sam proces. Jedna z potwierdzonych ścieżek ataku prowadzi przez mechanizm śledzenia postępu wysyłania plików w sesji (session upload progress), który jest domyślnie włączony.

Podatne są wszystkie popularne sposoby uruchamiania PHP: Apache z mod_php (według zespołu PHP najwyższe ryzyko), PHP-FPM, php-cgi, FrankenPHP i LiteSpeed.

Które wersje PHP są bezpieczne

Dla gałęzi 7.4, 8.0 i 8.1 zespół PHP opublikował jedynie minimalne łatki do samodzielnej kompilacji – w praktyce na typowym hostingu oznacza to, że stare wersje PHP pozostają podatne. Pamiętaj też, że dystrybucje Linuksa (np. Debian, Ubuntu) często wprowadzają poprawki bez zmiany głównego numeru wersji – w takim przypadku sprawdź komunikat bezpieczeństwa dystrybucji.

Jeśli Twoja strona działa na PHP 7.x lub 8.1, nie czekaj na poprawkę, bo jej nie będzie. Jedyne rozwiązanie to przejście na wspieraną wersję PHP – a to często wymaga aktualizacji CMS-a, wtyczek lub kodu.

Jak sprawdzić wersję PHP na swojej stronie

1. WordPress: w panelu wejdź w Narzędzia → Zdrowie witryny → Informacje → Serwer. Znajdziesz tam dokładny numer wersji PHP.
2. Panel hostingu: większość polskich hostingów pokazuje wersję PHP w ustawieniach domeny lub konta (często z możliwością jej zmiany jednym kliknięciem).
3. Własny serwer: polecenie php -v w konsoli pokaże wersję CLI, ale wersja obsługująca stronę (PHP-FPM, mod_php) może być inna – sprawdź ją bezpośrednio w konfiguracji serwera WWW.

Masz stronę na PHP? Zrób to teraz

1. Zaktualizuj PHP do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 (albo nowszej). To jedyna pełna poprawka.
2. Na hostingu współdzielonym aktualizację instaluje dostawca. Sprawdź jego komunikaty lub zapytaj wprost, kiedy serwery zostały załatane – i upewnij się, że Twoja domena nie korzysta ze starej wersji PHP wybranej kiedyś ręcznie w panelu.
3. Na własnym serwerze lub VPS po aktualizacji zrestartuj wszystkie procesy PHP (PHP-FPM, Apache). Przebuduj też obrazy Dockera – stary kod w działających procesach wciąż jest podatny.
4. Jeśli nie możesz zaktualizować od razu, zespół PHP zaleca tymczasowo: wyłączenie śledzenia postępu uploadu (session.upload_progress.enabled = 0), niski limit post_max_size (np. 8M bez uploadu plików, 32M z uploadem), a na PHP 8.5 także fatal_error_backtraces = 0. Te kroki zmniejszają ryzyko, ale nie czynią instalacji bezpieczną. CISA idzie dalej i zaleca, by niezałatane systemy oraz serwery z PHP 8.1 i starszym wyłączyć do czasu aktualizacji.
5. Zrób kopię zapasową plików i bazy – najlepiej taką, o której wiesz, że powstała przed 17 października.

Trzecia luka: CVE-2026-115560

23 października zespół PHP opublikował dodatkowe ostrzeżenie o kolejnej luce, CVE-2026-115560, której poprawki z 21 października nie usuwają. Dotyczy ona jednak nietypowej konfiguracji: aplikacja musi w trakcie działania zmieniać sposób zapisu sesji (session.serialize_handler) przed uruchomieniem sesji, a śledzenie postępu uploadu musi być włączone. Do 26 października nie odnotowano ataków z jej użyciem.

Poprawka ma pojawić się w najbliższym regularnym wydaniu PHP. Do tego czasu zespół PHP zaleca pozostawienie session.upload_progress.enabled = 0 – zwłaszcza jeśli włączyłeś to ustawienie już przy PHP2Shell.

Skąd wiedzieć, czy ktoś już się włamał

Aktualizacja zamyka drzwi, ale nie usuwa intruza, który mógł wejść wcześniej. Według analizy Datadog udany atak może zwrócić zwykłą odpowiedź HTTP 200 i nie zostawić widocznej awarii, dlatego warto przejrzeć serwer pod kątem:

• plików PHP w katalogach na uploady (np. wp-content/uploads w WordPressie) – nie powinno ich tam być,
• nieznanych kont administratorów w CMS-ie i nowych użytkowników w panelu hostingu,
• nietypowych błędów w logach, np. serii błędów „Allowed memory size … exhausted” z dopiskiem „Unknown on line 0” albo awarii procesów Apache (segmentation fault),
• procesów powłoki (shell) uruchamianych przez serwer WWW – to najbardziej bezpośredni ślad udanego ataku,
• zmodyfikowanych plików rdzenia CMS-a i wtyczek oraz nieznanych zadań cron.

Jeśli znajdziesz ślady włamania, odetnij stronę od internetu, zachowaj logi, zmień wszystkie hasła i klucze (baza danych, FTP/SSH, panel, klucze API) i odtwórz serwis z czystej kopii.

Czego uczy PHP2Shell

1. Aktualizacje to nie tylko wtyczki

Wielu właścicieli stron pilnuje aktualizacji WordPressa i wtyczek, ale nigdy nie sprawdza wersji PHP ani systemu serwera. Ta luka pokazuje, że warstwa „pod spodem” jest równie ważna.

2. Stara wersja PHP to dług, który kiedyś trzeba spłacić

Strony działające latami na PHP 7.x są dziś bez oficjalnej ochrony. Migracja na nowsze PHP wykonana spokojnie i z testami jest dużo tańsza niż ta robiona w pośpiechu po włamaniu.

3. Liczą się godziny, nie tygodnie

Ataki zaczęły się, zanim poprawki zostały opublikowane. Warto wiedzieć z góry, kto odpowiada za aktualizację serwera: Ty, hosting czy firma, która wykonała stronę.

Potrzebujesz pomocy?

Jeśli nie wiesz, na jakiej wersji PHP działa Twoja strona, albo boisz się, że aktualizacja coś zepsuje – pomożemy. W ramach audytu bezpieczeństwa sprawdzamy wersję PHP i konfigurację serwera, aktualność CMS-a i wtyczek, szukamy śladów włamania oraz przygotowujemy bezpieczną migrację na wspieraną wersję PHP.

Napisz do nas – przygotujemy bezpłatną wycenę dla Twojej strony.

Źródła

• PHP.net – komunikaty bezpieczeństwa z 21 i 23 października 2026 r.
• CISA – Critical Vulnerabilities in PHP Require Immediate Patching
• Datadog Security Labs – PHP2Shell: detection, analysis, and remediation
• SOC Prime – CVE-2026-115560: Unpatched PHP RCE Vulnerability
• testhub.pl – Krytyczne luki w PHP: co zrobić