21 października 2026 PHP wydało pilne poprawki dla dwóch krytycznych luk bezpieczeństwa w samym silniku języka. Obie mają ocenę CVSS 9.2 i pozwalają na nieuwierzytelnione zdalne wykonanie kodu (RCE) na serwerach obsługujących żądania HTTP. Zbiorczo nazwano je PHP2Shell (CVE-2026-109618 i CVE-2026-109619). Dotyczą praktycznie wszystkich instalacji PHP obsługujących strony www – od starych wersji aż po najnowsze przed łataniem.
To nie jest kolejna luka w wtyczce WordPressa czy frameworku. Problem leży w samym runtime’ie PHP, w zarządzaniu pamięcią i obsłudze błędów fatalnych. Atak może nastąpić zanim w ogóle uruchomi się kod Twojej aplikacji.
Jak działają te dwie luki?
CVE-2026-109618 – RCE przez uszkodzenie przy braku pamięci (OOM)
Gdy PHP w trakcie obsługi żądania dochodzi do limitu pamięci (memory_limit) w złym momencie, przerywa pracę i zostawia częściowo zainicjalizowane dane wewnętrzne. Późniejszy cleanup traktuje te niekompletne dane jak poprawne, co może prowadzić do uszkodzenia pamięci i wykonania kodu atakującego. Na Apache z mod_php da się to wywołać pojedynczym nieuwierzytelnionym żądaniem, zanim jakikolwiek kod aplikacji się uruchomi. RCE potwierdzono też na PHP-FPM (przez ścieżki aplikacyjne).
CVE-2026-109619 – RCE przez „stary” stan globalny (stale global state / use-after-free)
Worker PHP obsługuje wiele żądań po kolei. Gdy żądanie kończy się błędem fatalnym w złym miejscu, wewnętrzny stan (np. związany z sesjami, backtrace’ami błędów czy OPcache) może wskazywać na pamięć, która już została zwolniona. Następne żądanie na tym samym workerze może tę pamięć wykorzystać. Jedna z potwierdzonych ścieżek prowadzi przez mechanizm śledzenia postępu uploadu sesji (session.upload_progress), który domyślnie jest włączony i działa jeszcze przed session_start(). RCE pokazano m.in. na realnej aplikacji pod Apache + mod_php.
W skrócie: obie luki pozwalają atakującemu sterować pamięcią procesu PHP i w efekcie wykonać własny kod. Mogą też prowadzić do wycieków pamięci w stylu Heartbleed.
Kogo to dotyczy
Wszystkich instalacji PHP obsługujących żądania webowe: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP, LiteSpeed i podobne. Najwyższe ryzyko jest przy mod_php, bo atak może zadziałać jeszcze przed przekazaniem kontroli do aplikacji. Oficjalne łatki wyszły tylko dla wspieranych gałęzi:
– PHP 8.5 → 8.5.12
– PHP 8.4 → 8.4.27
– PHP 8.3 → 8.3.36
– PHP 8.2 → 8.2.35
Wersje 8.1 i starsze nie dostały oficjalnych binarek od projektu PHP (są end-of-life). Dostępne są minimalne backporty źródeł dla 7.4, 8.0 i 8.1, ale lepiej przejść na wspieraną wersję. PHP 8.2 kończy wsparcie 31 grudnia 2026 – to dobry moment, żeby zaplanować migrację.
Co robić – aktualizacja to jedyna pełna ochrona
1. Zaktualizuj PHP jak najszybciej.
To jedyna kompletna ochrona. Sprawdź pakiety swojej dystrybucji (wiele dostało łatki wcześniej), obrazy Dockera, hosting czy panel. Po aktualizacji zrestartuj workery (PHP-FPM, Apache itd.), bo stare procesy dalej działają na podatnym kodzie.
2. Tymczasowe środki (jeśli nie możesz zaktualizować od razu).
Nie dają pełnej ochrony, ale zmniejszają powierzchnię ataku. Stosuj je tylko na czas do łatki i pamiętaj o restarcie workerów:
– Wyłącz session.upload_progress.enabled = 0 w php.ini / konfiguracji FPM / serwera (nie przez ini_set() – za późno).
– Na PHP 8.5 wyłącz fatal_error_backtraces = 0.
– Ustaw memory_limit = -1 tak, żeby aplikacja nie mogła tego nadpisać (np. php_admin_value w FPM). Uwaga: to wyłącza ochronę przed wyczerpaniem pamięci.
– Ogranicz rozmiar żądań: obniż post_max_size (np. 8M lub 32M przy uploadach), upload_max_filesize poniżej niego, limity na poziomie serwera/proxy.
– Rozważ pm.max_requests = 1 (częstsze restarty workerów) oraz limity pamięci kontenera/cgroup.
Unikaj RLIMIT_AS / RLIMIT_DATA – mogą same wywołać podatną ścieżkę.
3. Dodatkowe kroki.
Sprawdź logi pod kątem nietypowych błędów pamięci, fatal errorów czy podejrzanych żądań multipart. Na starszych wersjach rozważ tymczasowe odcięcie od sieci publicznej albo WAF, jeśli aktualizacja się przeciąga. Po łatce zweryfikuj, że nowa wersja faktycznie działa.
PHP2Shell to jedna z poważniejszych historii w PHP od lat – dotyczy rdzenia, działa na ogromnej części internetu i pozwala na RCE bez uwierzytelnienia. Dobra wiadomość jest taka, że łatki są już dostępne i większość dystrybucji oraz hostingu powinna je szybko wdrożyć. Jeśli masz serwery z PHP – zaktualizuj je dzisiaj. Jeśli zarządzasz starszymi wersjami – zaplanuj migrację. A jeśli dopiero budujesz infrastrukturę, traktuj to jako przypomnienie, że nawet „stabilny” język runtime wymaga regularnych aktualizacji. Masz pytania dotyczące konkretnej konfiguracji (FPM, Docker, konkretna dystrybucja)? Daj znać w komentarzach.
