PHP2Shell: dwie luki w rdzeniu PHP pozwalają przejąć serwer bez logowania

Dlaczego problem dotyczy prawie każdego serwera z PHP

PHP2Shell to wspólna nazwa dwóch błędów w samym interpreterze PHP: CVE-2026-109618 i CVE-2026-109619, obu z oceną CVSS v4.0 9.2. Skoro problem siedzi w silniku, nie ma znaczenia, czy na serwerze działa WordPress, sklep czy pojedynczy formularz. Wystarczy, że PHP obsługuje żądania z sieci.

Pierwszy błąd dotyczy braku pamięci: przerwane w złym momencie żądanie zostawia w połowie zainicjalizowane dane, które sprzątanie traktuje jak poprawne. Drugi to use-after-free: stan jednego żądania przeżywa zwolnienie pamięci i może go użyć kolejne żądanie w tym samym procesie. W obu przypadkach atakujący uruchamia własny kod z uprawnieniami konta, na którym działa serwer WWW.

Kto jest naprawdę narażony

Producent wymienia wszystkie instalacje obsługujące żądania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed.

• Apache z mod_php: tu zespół PHP pokazał działający exploit. Niezalogowane żądanie uruchamia atak, zanim wykona się jakikolwiek kod aplikacji, więc logowanie, framework i zabezpieczenia w samej aplikacji nic nie dają.
• PHP-FPM i pozostałe tryby: podatność wynika z analizy kodu, pełnego exploita nie pokazano.
• PHP 8.1 i starsze: projekt PHP ich już nie łata. Część dystrybucji i dostawców LTS ma własne backporty, a zespół PHP przygotował minimalne łatki źródłowe dla 7.4, 8.0 i 8.1.

Ataki zaczęły się przed łatką. Według Amazon Threat Intelligence, na którego dane powołuje się BleepingComputer, pierwsze próby trafiły w pułapkę typu honeypot 17 października, cztery dni przed wydaniem poprawek. Nie wiadomo, ile prób się powiodło. W chwili pisania podatności nie ma w katalogu CISA KEV.

Podatne i poprawione wersje

• PHP 8.5 przed 8.5.12
• PHP 8.4 przed 8.4.27
• PHP 8.3 przed 8.3.36
• PHP 8.2 przed 8.2.35

Dystrybucje i dostawcy LTS dostali poprawki wcześniej, więc pakiet z niższym numerem może już zawierać łatkę (backport). Wersję z dpkg -l | grep php lub rpm -qa | grep php porównajcie z biuletynem bezpieczeństwa dystrybucji.

Kolejność prac: dziś i w najbliższym oknie serwisowym

Dziś:

• każdy serwer dostępny z internetu z PHP 8.2–8.5, zaczynając od tych z mod_php;
• wystawione do sieci serwery z PHP 8.1 lub starszym: pakiet od dostawcy LTS, łatka źródłowa albo przynajmniej obejścia opisane niżej. Brytyjskie NCSC zaleca aktualizację albo wyłączenie serwera do czasu wgrania poprawki.

W najbliższym oknie serwisowym:

• serwery dostępne tylko z sieci wewnętrznej lub przez VPN, środowiska testowe i deweloperskie;
• przebudowa obrazów Docker i szablonów maszyn, żeby nowe instancje nie startowały ze starą wersją;
• plan przejścia z PHP 8.2, które traci wsparcie 31 grudnia 2026.

Gdzie może się ukrywać stara wersja

1. Wersja CLI i FPM bywa różna. Sprawdźcie obie: php -v oraz php-fpm -v (nazwa zależy od dystrybucji, np. php-fpm8.3 -v).
2. Czy Apache ładuje mod_php: apachectl -M | grep -i php.
3. Kontenery: docker ps, a w każdym kontenerze z PHP docker exec NAZWA php -v. Aktualizacja hosta nie zmienia PHP zaszytego w obrazie.
4. Repozytorium rpms.remirepo.net nie miało poprawek w dniu wydania. Zespół PHP zaleca pakiety dystrybucji lub budowanie ze źródeł.
5. Hosting współdzielony, aplikacje dostawców z własnym PHP i zapomniane maszyny po dawnych projektach. Hostingodawcę zapytajcie wprost o wersję i datę aktualizacji.

Jeśli nie możecie zaktualizować od razu

Producent podaje obejścia, które zmniejszają ryzyko, ale nie zabezpieczają instalacji. Blokują potwierdzone ścieżki ataku, nie wszystkie warianty.

• CVE-2026-109618: memory_limit=-1 ustawione tak, żeby nic go nie nadpisało (php_admin_value w puli FPM lub konfiguracji Apache), post_max_size 8M bez uploadu plików albo 32M z uploadem, limity rozmiaru żądań na serwerze WWW lub proxy. Pamięć ograniczcie limitem kontenera lub cgroup, ale nie używajcie RLIMIT_AS ani RLIMIT_DATA, bo same mogą wywołać podatny błąd alokacji.
• CVE-2026-109619: session.upload_progress.enabled=0 w php.ini lub konfiguracji puli, na PHP 8.5 dodatkowo fatal_error_backtraces=0, potem restart wszystkich procesów. ini_set() ani .user.ini nie wystarczą.

Czego szukać w logach

Ataki trwają od 17 października, więc na serwerach dostępnych z internetu sama aktualizacja nie zamyka sprawy. Producent nie podał wskaźników włamania. Z mechanizmu błędów wynika, gdzie patrzeć:

• logi serwera WWW: nietypowo duże żądania multipart, zwłaszcza do stron bez formularzy z uploadem;
• logi PHP: serie błędów „Allowed memory size exhausted” z jednego źródła;
• logi PHP-FPM i Apache: procesy kończące się sygnałem (np. SIGSEGV) i nagłe restarty;
• dysk: nowe lub zmienione pliki PHP w katalogach WWW, np. find /var/www -name '*.php' -newermt 2026-10-17, oraz zmiany w crontabie konta serwera WWW.

Jeśli któryś z tych śladów się potwierdzi, traktujcie serwer jako przejęty: odizolujcie go, zabezpieczcie logi, odtwórzcie system z czystego stanu i zmieńcie dostępne z niego hasła oraz klucze.

Wniosek na dłużej

Tym razem ataki wyprzedziły łatkę, więc zwykły cykl aktualizacji nie wystarczył. Firma z aktualnym spisem serwerów, kontenerów i wersji PHP oraz przećwiczoną aktualizacją w ciągu dnia zamyka taki temat w jedno popołudnie. Bez spisu pierwszy dzień schodzi na ustalaniu, gdzie PHP w ogóle działa. Plan dla wersji bez wsparcia, takich jak PHP 8.2 od stycznia, przygotujcie z wyprzedzeniem.