PHP2Shell: Krytyczne luki w PHP najmocniej dotykają serwery mod_php

Zespół PHP przyspieszył wydanie aktualizacji bezpieczeństwa na środę, 21 października, na godz. 14:00 UTC po tym, jak dzień wcześniej szczegóły dwóch luk wyciekły w serwisie Hacker News. Poprawki trafią do PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Oba błędy znajdują się w samym interpreterze, a nie w systemie CMS. Komunikaty bezpieczeństwa PHP dotyczące CVE-2026-109618 i CVE-2026-109619 przyznają każdej z luk ocenę 9,2 w skali CVSS 4.0 i potwierdzają możliwość zdalnego wykonania kodu bez uwierzytelniania, z uprawnieniami procesu roboczego serwera WWW.

Obsługa braku pamięci pozostawia pamięć częściowo zainicjalizowaną

Pierwsza luka sprowadza się do sposobu, w jaki PHP obsługuje błędy braku pamięci. W przypadku OOM interpreter używa longjmp(), aby opuścić bieżący kontekst, nawet jeśli pamięć żądania jest w tym momencie tylko częściowo zainicjalizowana. Procedura zamykania traktuje następnie ten stan jako prawidłowy. Atakujący może wymusić OOM za pomocą żądania multipart, które nie przekracza post_max_size, na przykład przez nieograniczoną liczbę nagłówków w każdej części, puste pola plików, które nie wliczają się do max_file_uploads, lub zagnieżdżone nazwy pól. Poprawka zastępuje longjmp() łagodną obsługą OOM w najbliższym bezpiecznym punkcie maszyny wirtualnej oraz bezwarunkowym wywołaniem _exit() po przekroczeniu drugiego, wyższego progu.

Druga luka dotyczy stanu globalnego, który utrzymuje się po zakończeniu żądania. Jeśli błąd krytyczny przerywa operację, zanim zresetuje ona swój stan, pole globalne nadal wskazuje na zwolnioną pamięć sterty. Gdy kolejne żądanie obsługiwane przez ten sam proces roboczy odczytuje tę wartość przed standardową inicjalizacją, dochodzi do użycia pamięci po jej zwolnieniu (use-after-free). PHP wymienia dwie potwierdzone ścieżki: ustawienie fatal_error_backtraces w PHP 8.5 oraz mechanizm śledzenia postępu przesyłania plików w sesji, który jest domyślnie włączony i nie wymaga wywołania session_start() przez aplikację.

Dlaczego mod_php jest najbardziej narażony

Apache z mod_php wywołuje procedurę zamykania żądania nawet wtedy, gdy jego inicjalizacja już się nie powiodła. Wystarczy wyczerpanie pamięci podczas parsowania treści żądania przez PHP, a żaden kod aplikacji nie musi zostać uruchomiony. Zespół PHP potwierdził możliwość pełnego wykonania kodu w środowisku mod_php z domyślnymi limitami pamięci i danych wejściowych. PHP-FPM kończy proces potomny, którego inicjalizacja się nie powiodła, co blokuje bezpośrednią ścieżkę ataku. W przypadku drugiej luki zespół PHP potwierdził jednak skuteczność exploita wobec standardowej puli FPM, choć zależy ona od odpowiedniej operacji w aplikacji. Analiza kodu źródłowego sugeruje, że FrankenPHP zachowuje się podobnie do mod_php, natomiast LSAPI może być podatne pod pewnymi warunkami. Wysoka złożoność ataku w wektorze CVSS odzwierciedla fakt, że kompilacja PHP i układ sterty wpływają na niezawodność exploita.

Próby wykorzystania luk i rola AI

watchTowr informuje, że obserwuje aktywne próby wykorzystania obu luk, a Cloudflare przekazał serwisowi The Hacker News, że odnotował pierwsze ataki jeszcze przed wydaniem poprawki. Dotychczas nie potwierdzono żadnego udanego włamania. Mimo to holenderskie usługi administracji publicznej, w tym DigiD i MijnOverheid, zostały zapobiegawczo wyłączone, a brytyjskie NCSC zaleca odłączenie niezałatanych systemów od sieci, jeśli nie ma innej możliwości.

Zespół Wiz Research odkrył błędy i zgłosił je 24 sierpnia. Według Wiz modele Gemini 4 Argon i GPT-5.6 Sol pomogły w wykrywaniu luk, opracowywaniu exploitów i weryfikacji poprawek, zwłaszcza w dostosowywaniu exploita do poszczególnych celów. Wiz przypisuje również OpenAI i Calif pomoc w odkryciu luk i koordynacji działań. Wpisuje się to w niedawny opis Anthropic dotyczący samokopiującej się AI atakującej tanie przystawki telewizyjne, gdzie modele również obniżają próg wejścia dla atakujących.

Co administratorzy powinni zrobić teraz

Aktualizacja jest jedynym kompletnym rozwiązaniem. Dystrybucje Linuksa i dostawcy wersji LTS otrzymali poprawki z wyprzedzeniem i często przenoszą je do starszych wersji bez zmiany ich numeracji, dlatego należy sprawdzić identyfikatory CVE w rejestrze zmian, zamiast kierować się numerem wersji. Niewspierane gałęzie 7.4, 8.0 i 8.1 otrzymują jedynie minimalne poprawki przeniesione do kodu źródłowego. Jeśli nie możesz od razu przeprowadzić aktualizacji, PHP zaleca ustawienie memory_limit=-1 na poziomie administracyjnym, ponieważ to przewidywalny limit pamięci na żądanie umożliwia działanie potwierdzonego exploita wykorzystującego OOM. Dodaj session.upload_progress.enabled=0, a w PHP 8.5 także fatal_error_backtraces=0, a następnie uruchom ponownie wszystkie procesy robocze. Jeśli aplikacja nie korzysta z formularzy multipart, zablokuj je na warstwie wejściowej. Żadne z tych ustawień nie stanowi pełnego rozwiązania. W przypadku hostingu współdzielonego lub urządzenia NAS z serwerem WWW sprawdź, jaką wersję PHP dostarcza Twój dostawca.