Krytyczna luka w PHP. Te wersje trzeba zaktualizować natychmiast
By Paweł Lisowski
Twórcy PHP wydali pilne poprawki dla dwóch krytycznych luk, które mogą pozwolić na zdalne wykonanie kodu bez uwierzytelnienia. Problem dotyczy instalacji obsługujących żądania internetowe, między innymi PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Jeśli serwer korzysta z PHP, aktualizacja powinna być teraz priorytetem.
Dlaczego PHP2Shell jest tak groźne?
Luki oznaczone jako CVE-2026-109618 i CVE-2026-109619 znajdują się w samym silniku PHP, a nie w konkretnym CMS-ie. Badacze Wiz zademonstrowali odczyt pamięci procesu oraz wykonanie kodu bez logowania na środowiskach z WordPressem, Drupalem i Joomlą. Oznacza to, że aktualna aplikacja nie musi zawierać własnego błędu, aby serwer był narażony.
Wiz opisał też rolę modeli AI w badaniu. Skomplikowane łańcuchy błędów związane z obsługą pamięci i stanem procesów były trudne do wykorzystania ręcznie, ale modele pomogły analizować wyniki testów i dostosowywać exploit do różnych konfiguracji. Nie oznacza to jednak, że każde PHP używane przez około 70 proc. stron jest automatycznie podatne w identyczny sposób. Ryzyko zależy między innymi od wersji, konfiguracji i sposobu uruchamiania PHP.
Jakie wersje PHP trzeba zaktualizować?
Oficjalne poprawki to PHP 8.5.12, 8.4.27, 8.3.36 oraz 8.2.35. PHP 8.1 i starsze nie są już aktualizowane przez główny projekt, dlatego administratorzy powinni sprawdzić, czy ich dystrybucja lub dostawca wsparcia udostępnił poprawkę wsteczną. W przeciwnym razie bezpieczniejszą drogą jest przejście na wspieraną gałąź.
Jeżeli aktualizacja nie może zostać wykonana od razu, dokumentacja PHP opisuje ograniczenia zmniejszające ekspozycję na wybrane ścieżki ataku, między innymi wyłączenie session.upload_progress.enabled przed rozpoczęciem przetwarzania żądania i ponowne uruchomienie pracowników. To tylko środki tymczasowe. Twórcy PHP podkreślają, że pełnym rozwiązaniem pozostaje aktualizacja.
Cloudflare poinformował, że wdrożył reguły WAF chroniące przed PHP2Shell jeszcze przed publicznym ujawnieniem luk. Taka warstwa może pomóc ograniczyć część ruchu, ale nie zastępuje aktualizacji samego interpretera. Po wdrożeniu poprawki warto dodatkowo przejrzeć logi, historię procesów PHP i nietypowe błędy 500.
Źródła
Autor Artykułu
Paweł Lisowski
Paweł Lisowski - pasjonat technologii, komputerów i internetu. Od wielu lat śledzi rozwój sprzętu i oprogramowania, testuje nowe rozwiązania i dzieli się wiedzą z czytelnikami. Zafascynowany wpływem technologii na codzienne życie, tworzy praktyczne poradniki i inspiruje do świadomego korzystania z cyfrowego świata.