PHP2Shell trafił na listę CISA. Administratorzy mają tylko dni na aktualizację
By Paweł Lisowski
Niezałatane instalacje PHP są już wykorzystywane w atakach. Amerykańska agencja CISA dodała dwie luki znane jako PHP2Shell, oznaczone CVE-2026-109618 i CVE-2026-109619, do katalogu Known Exploited Vulnerabilities. Cywilne agencje federalne USA mają zabezpieczyć systemy do 29 października.
To ważna zmiana oceny ryzyka. Po publikacji poprawek 21 października badacze obserwowali próby ataków, ale brakowało publicznego potwierdzenia skutecznego wykonania kodu. W weekend Adel Karimi z zespołu Perplexity opisał działanie łańcucha na honeypotach: niezałatany serwer Apache z mod_php i PHP 8.4.26 uruchomił kod atakującego. CISA nie ujawniła szczegółów trwających kampanii.
Dlaczego PHP2Shell jest tak groźny
Obie luki pozwalają nieuwierzytelnionemu napastnikowi na zdalne wykonanie kodu. CVE-2026-109618 wiąże się z błędną obsługą błędu braku pamięci, a CVE-2026-109619 z pozostałościami stanu wewnętrznego żądania po zwolnieniu pamięci. W najbardziej ryzykownym scenariuszu atak może zostać uruchomiony jeszcze przed wykonaniem kodu aplikacji.
Problem dotyczy każdego PHP obsługującego żądania internetowe, w tym PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Nie oznacza to, że każda aplikacja jest równie łatwa do zaatakowania, ale sama obecność podatnego interpretera wymaga sprawdzenia. PHP jest warstwą, na której działają między innymi systemy CMS, sklepy i narzędzia administracyjne.
Jakie wersje PHP są bezpieczne
PHP Group wydała poprawki w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Gałęzie 8.1 i starsze nie są już regularnie aktualizowane przez projekt, choć część dystrybucji i dostawców LTS może dostarczać własne backporty. Administrator powinien sprawdzić także PHP dołączone do paneli, urządzeń i gotowych aplikacji.
Aktualizacja to jedyne pełne rozwiązanie. Tymczasowe ustawienia, takie jak wyłączenie session.upload_progress.enabled, mogą ograniczyć wybrane ścieżki ataku, ale nie zastępują poprawki. Po wdrożeniu aktualizacji warto przejrzeć logi serwera, procesy uruchamiane przez PHP i webroot pod kątem nowych plików PHP. Sam restart pracowników nie usuwa śladów wcześniejszego włamania.
Ź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.