PHP2Shell: dwie krytyczne luki w PHP i co zrobić na hostingu

Aktualizacja: poprawki są już dostępne. Zmiana konfiguracji hostingu może ograniczyć część ataków, ale nie zastępuje aktualizacji PHP.

PHP2Shell to nazwa związana z dwiema podatnościami: CVE-2026-109618 oraz CVE-2026-109619. Błędy dotyczą zarządzania pamięcią w interpreterze i mogą prowadzić do zdalnego wykonania kodu bez logowania. To problem samego PHP, dlatego aktualizacja WordPressa, Joomli czy dodatków do sklepu nie naprawia podatnego interpretera. Oficjalny komunikat projektu PHP wskazuje wydania, w których luki zostały zamknięte.

PHP2Shell — co jest podatne i jakie wersje PHP instalować

Twórcy PHP ostrzegają przed ryzykiem dla instalacji obsługujących żądania WWW, w tym PHP-FPM, Apache z mod_php, CGI, FrankenPHP i LiteSpeed. Najwyższe ryzyko wskazują dla mod_php.

Obie luki naprawiono w następujących wydaniach: biuletyny CVE-2026-109618 i CVE-2026-109619.

Starszych gałęzi nie należy uznawać za bezpieczne. PHP 8.1 i wcześniejsze są poza standardowym wsparciem projektu. Dostawcy systemów mogą udostępniać własne poprawki, a dla wybranych starszych gałęzi opublikowano awaryjne łatki źródłowe. Status konkretnego pakietu trzeba sprawdzić u jego dostawcy.

Pierwszy krok: sprawdź wszystkie instalacje PHP

Na hostingu jedno polecenie php -v może pokazać wyłącznie wersję używaną w terminalu. Strony, zadania cykliczne i panel administracyjny mogą korzystać z innych interpreterów oraz innych plików konfiguracyjnych.

W moim przypadku pracę zacząłem od przeglądu procesów, usług i konfiguracji. Osobno sprawdziłem ustawienia bazowe oraz nadpisania w pulach PHP-FPM. Dopiero potem wykonałem kopie plików, zmiany, testy konfiguracji i restarty odpowiednich usług. Taka inwentaryzacja jest ważna przy każdej zmianie dotyczącej PHP2Shell, bo jeden serwer może obsługiwać strony kilkoma różnymi instalacjami PHP.

Czy trzeba wyłączyć przesyłanie plików?

Ustawienie:

session.upload_progress.enabled = Off

wyłącza sesyjne śledzenie postępu przesyłania plików. Sam upload pozostaje dostępny; aplikacja korzystająca z tego mechanizmu może stracić informację o postępie.

W kontekście CVE-2026-109619 blokuje to potwierdzone ścieżki związane z obsługą sesji, ale nie wszystkie warianty błędu. Zmianę należy zastosować przed przetwarzaniem żądania, np. w php.ini lub konfiguracji puli PHP-FPM, i zrestartować wszystkie procesy PHP. W PHP-FPM samo .user.ini lub ini_set() nie wystarcza dla tego zabezpieczenia. Dla PHP 8.5 zalecane jest dodatkowo:

fatal_error_backtraces = Off

Limity żądań pomagają, ale mają koszt

Przykładowe, restrykcyjne limity dla aplikacji niewymagającej dużych uploadów:

post_max_size = 8M
upload_max_filesize = 2M
max_input_vars = 1000

Ograniczają rozmiar danych i liczbę zmiennych wejściowych. Mogą jednak utrudnić importy, przesyłanie większych plików lub zapis rozbudowanych formularzy. Trzeba też sprawdzić nadpisania dla poszczególnych pul i stron. Twórcy PHP zalecają ograniczanie żądań również na serwerze WWW lub reverse proxy.

Skąd bierze się zalecenie memory_limit = -1

CVE-2026-109618 wykorzystuje nieprawidłową obsługę sytuacji braku pamięci. Administracyjnie wymuszone memory_limit = -1 usuwa przewidywalny próg błędu wynikający z limitu PHP. Nie chroni jednak przed rzeczywistym niepowodzeniem alokacji pamięci.

To jednocześnie zniesienie limitu pamięci pojedynczego żądania. Wymaga oceny zasobów, równoległości procesów i ograniczeń na poziomie systemu. Skończony limit, np. 128M, nie zapewnia tej samej częściowej ochrony co memory_limit = -1.

Po zmianach: kontrola konfiguracji i aktualizacja

Przed restartem warto sprawdzić składnię konfiguracji. Po nim — status usług, działanie stron i rzeczywiste wartości ustawień. Odczyt wykonany nowym procesem PHP potwierdza konfigurację z dysku, ale sam w sobie nie dowodzi, że każda pula i strona używa identycznych wartości.

Zmniejszenie ryzyka to etap przejściowy. Docelowym działaniem jest instalacja pakietów PHP naprawiających obie podatności i restart procesów korzystających ze starego kodu.

Praktyczna checklista dla hostingu

• Zrób spis wszystkich instalacji PHP: interpretery, pule PHP-FPM, pliki konfiguracyjne, zadania cykliczne.
• Porównaj każdą wersję z tabelą wydań z poprawkami dla PHP2Shell.
• Ustawienia osłonowe (session.upload_progress.enabled = Off, fatal_error_backtraces = Off) zastosuj w plikach czytanych przed obsługą żądania.
• Przetestuj limity żądań na własnych formularzach i importach, nie tylko na wartościach domyślnych.
• memory_limit = -1 oceniaj świadomie: to część ochrony, ale otwarte zużycie pamięci pojedynczego procesu.
• Aktualizacja PHP do wydania z poprawkami zamyka obie luki w PHP — to cel końcowy, a restart procesów jest jego częścią.
• Po każdej zmianie zweryfikuj status usług i rzeczywiste ustawienia każdej puli.

O pozostałych działaniach na serwerze i hostingu piszę też w dziale bezpieczeństwo.

Najczęściej zadawane pytania

Jeśli chcesz, żebym wspólnie z agentem przejrzał konfigurację PHP na Twoim hostingu i przygotował plan aktualizacji, napisz do mnie.

Źródła

• Komunikat bezpieczeństwa PHP i wydania z poprawkami
• Biuletyn CVE-2026-109618 — RCE przez uszkodzenie pamięci przy jej braku
• Biuletyn CVE-2026-109619 — RCE przez nieaktualny stan globalny
• Dokumentacja PHP — śledzenie postępu uploadu
• Dokumentacja PHP — podstawowe ustawienia i limity żądań