PHP2Shell: krytyczne luki dostały łatki. Administratorzy nie mogą zwlekać
By Paweł Lisowski
Spis treści
Dwie krytyczne luki w jądrze PHP pozwalały na zdalne wykonanie kodu bez logowania do serwera. Projekt PHP opublikował poprawki 21 października, ale administratorzy nie powinni traktować aktualizacji jako zadania na później. Podatne mogą być nie tylko strony internetowe, lecz także kontenery, obrazy systemowe i urządzenia korzystające z PHP.
Problemy otrzymały oznaczenia CVE-2026-109618 i CVE-2026-109619 oraz wspólną nazwę PHP2Shell. Oficjalny komunikat PHP wskazuje, że atakujący może wysłać spreparowane żądanie do instalacji obsługującej ruch internetowy i doprowadzić do wykonania własnego kodu. Najwyższe ryzyko dotyczy środowisk używających między innymi PHP-FPM, mod_php, php-cgi, FrankenPHP i LiteSpeed.
Co dokładnie poszło nie tak?
Obie luki dotyczą zarządzania pamięcią podczas obsługi żądania. CVE-2026-109618 wiąże się z sytuacją, w której PHP kończy pracę z powodu wyczerpania pamięci, zanim wszystkie dane wewnętrzne zostaną prawidłowo przygotowane. Późniejsze sprzątanie może wtedy potraktować nieprawidłowy stan jako poprawny. W przypadku CVE-2026-109619 proces może zachować odwołanie do pamięci zwolnionej po zakończeniu wcześniejszego żądania.
W praktyce nie chodzi o błąd konkretnego motywu WordPressa ani pojedynczej wtyczki. Problem znajduje się w środowisku uruchomieniowym PHP. Dlatego samo zaktualizowanie kodu strony nie wystarczy, jeśli serwer nadal korzysta z podatnej wersji interpretera.
Te wersje PHP trzeba zaktualizować
PHP opublikował wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35. To właśnie do nich powinni przejść użytkownicy odpowiednich gałęzi. Projekt zaznacza, że pełnym rozwiązaniem jest aktualizacja. Dla starszych, niewspieranych wersji dostępne są tylko wybrane łatki źródłowe lub poprawki przygotowane przez dystrybutora i dostawcę długoterminowego wsparcia.
Ważna jest kontrola całego łańcucha wdrożenia. Docker potwierdza, że podatne pakiety sięgają wstecz do PHP 5.4, a zagrożenie obejmuje także obrazy używane w kontenerach. Aktualizacja systemu gospodarza nie zmieni automatycznie interpretera umieszczonego we własnym obrazie. Po podniesieniu wersji trzeba więc przebudować obraz i wdrożyć go ponownie.
Dlaczego łatka jest pilna?
Atak nie wymaga kliknięcia w link ani podania hasła. Jeżeli serwer przyjmuje żądania z internetu i uruchamia podatne PHP, napastnik może próbować przejąć proces, odczytać dane, zmienić zawartość strony albo zainstalować dodatkowe złośliwe oprogramowanie. Cloudflare zwraca uwagę, że skutkiem błędów pamięci może być również ujawnienie informacji, a nie tylko awaria usługi.
Po ujawnieniu luk rośnie też tempo prób ich wykorzystania. W przypadku otwartego kodu poprawka pokazuje obrońcom, gdzie znajdował się problem, ale jednocześnie ułatwia napastnikom analizę różnic między wersją podatną a naprawioną. Z tego powodu opóźnianie aktualizacji zwiększa ryzyko, nawet jeśli konkretna strona nie korzysta z popularnego systemu CMS.
Co powinien zrobić administrator?
Najpierw należy ustalić, które serwery, kontenery, obrazy i urządzenia uruchamiają PHP oraz czy są dostępne z internetu. Następnie trzeba zaktualizować PHP do poprawionej wersji właściwej dla używanej gałęzi, przebudować obrazy kontenerów i sprawdzić pakiety dostarczane przez system operacyjny. Po wdrożeniu warto przejrzeć logi pod kątem nietypowych żądań, nowych procesów, zmian plików i nieoczekiwanych kont użytkowników.
Reguły zapory aplikacyjnej mogą ograniczyć część znanych wzorców ataku, ale nie zastępują aktualizacji. Jeśli natychmiastowa naprawa nie jest możliwa, ograniczenie ekspozycji serwera lub czasowe wyłączenie usługi jest bezpieczniejsze niż pozostawienie jej bez zmian. PHP zaleca również sprawdzenie zaleceń dystrybutora, szczególnie w przypadku starszych gałęzi i instalacji zarządzanych przez dostawcę hostingu.
PHP2Shell pokazuje, że pojedyncza warstwa często używanego oprogramowania może stać się wspólnym punktem ryzyka dla wielu stron i usług. Najważniejszy wniosek dla właścicieli serwerów jest prosty: trzeba sprawdzić wersję PHP wszędzie, także w kontenerach i urządzeniach, a następnie jak najszybciej wdrożyć poprawki.
Ź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.