Zespół PHP wydał 21 października awaryjne aktualizacje łatające dwie krytyczne luki, które pozwalają atakującemu wykonać dowolny kod na serwerze WWW bez logowania. Oba błędy — CVE-2026-109618 i CVE-2026-109619 — dostały ocenę 9,2 na 10 w skali CVSS v4, czyli najwyższy stopień krytyczności. Poprawki są w wersjach PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Całość ochrzczono nazwą PHP2Shell.
Dotyczy każdej instalacji obsługującej ruch WWW
Luki siedzą w samym interpreterze PHP, nie w konkretnej aplikacji, więc podatny jest każdy sposób uruchamiania PHP na serwerze: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najgorzej wygląda sytuacja przy mod_php — tam pojedyncze żądanie bez uwierzytelnienia uruchamia atak, zanim w ogóle zacznie działać kod strony. Oznacza to, że narażone są witryny na WordPressie, Drupalu, Magento, Joomli i Laravelu, jeśli tylko stoją na niezałatanej wersji PHP. Wiz Research, firma bezpieczeństwa, która zgłosiła błędy, twierdzi, że przynajmniej jedna z luk sięga wszystkich wydań PHP aż do 5.4, i pokazała zdalne wykonanie kodu na aktualnych obrazach WordPressa, Drupala i Joomli — a według niej wykorzystać da się nawet zwykłą aplikację „Hello World” na niezałatanym PHP.
Na czym polegają oba błędy
CVE-2026-109618 to błąd w obsłudze wyczerpania pamięci (OOM): PHP potrafi przerwać żądanie w momencie, gdy jego wewnętrzne dane są zainicjowane tylko częściowo, a procedura sprzątania po żądaniu traktuje potem te śmieci jak poprawne dane. CVE-2026-109619 pozwala, by wewnętrzny stan jednego żądania przetrwał zwolnienie pamięci — kolejne żądanie obsłużone przez tego samego workera może sięgnąć po te nieważne dane. Według Wiz te same mechanizmy dają się wykorzystać także do czytania pamięci procesów PHP, w której siedzą hasła, tokeny i klucze API.
Wiz podkreśla, że same błędy były w kodzie od dekad, ale zbudowanie z nich działającego exploita wymagało wyjątkowo złożonego łańcucha kroków — na granicy tego, co badacze mogli osiągnąć ręcznie. Barierę, jak twierdzi firma, obniżyły najnowsze modele AI, które coraz śmielej wchodzą w codzienną pracę techniczną.
Starsze gałęzie, LTS i remirepo
Dystrybucje Linuksa i dostawcy wsparcia długoterminowego (LTS) dostali łatki przed publicznym wydaniem, więc warto sprawdzić pakiety u swojego dostawcy. PHP 8.1 i starsze nie są już wspierane przez projekt, ale część dystrybucji i dostawców LTS udostępnia backporty; dodatkowo zespół bezpieczeństwa PHP przygotował minimalne backporty źródłowe dla PHP 7.4, 8.0 i 8.1 — dla tych, którzy kompilują PHP sami. Osobne ostrzeżenie dotyczy ochotniczego repozytorium rpms.remirepo.net: nie będzie miało aktualizacji tego dnia, więc PHP zaleca przejście na pakiety dystrybucyjne albo kompilację ze źródeł.
WAF Cloudflare i pierwsze skanowania
Dane Knecht, CTO Cloudflare, podał, że strony PHP stojące za Cloudflare mają już wdrożony wstępny zestaw reguł WAF (zapory aplikacyjnej) dla znanych wektorów ataku — dostępny dla wszystkich klientów, także w darmowym planie. Firma Patchstack, która monitoruje bezpieczeństwo WordPressa, informowała po wydaniu łatek, że w jej telemetrii widać na razie tylko próby skanowania, bez twardych dowodów na skuteczne włamania. Brytyjski NCSC wydał alert, w którym radzi organizacjom natychmiastową aktualizację, a tam gdzie nie jest to możliwe — rozważenie wyłączenia systemu do czasu zabezpieczenia. Część usług zdjęła serwery prewencyjnie jeszcze przed wydaniem poprawki — holenderski NOS wymienia m.in. DigiD i MijnOverheid, a japońskie ITmedia opisuje awaryjne prace serwisowe u kilku dużych operatorów, w tym Sakura Rental Server.
Jak sprawdzić swoją wersję PHP
Jeśli masz dostęp do serwera po SSH, wystarczy polecenie php -v — pokaże wersję interpretera z linii komend. Na współdzielonym hostingu wersję znajdziesz w panelu (sekcja ustawień PHP dla domeny), tam zwykle możesz też przełączyć gałąź jednym kliknięciem. Cel: 8.5.12, 8.4.27, 8.3.36 albo 8.2.35, zależnie od gałęzi, na której stoisz. Pamiętaj, że liczy się każda instalacja PHP w infrastrukturze, nie tylko strona główna: serwery testowe, środowiska w chmurze, kontenery oraz urządzenia i oprogramowanie firm trzecich, które mają PHP w środku. Po aktualizacji trzeba zrestartować procesy PHP, żeby workery faktycznie wystartowały z nowym kodem.