Dwie krytyczne luki w PHP pozwalają na zdalne wykonanie kodu

Mechanizm działania luk CVE-2026-109618 oraz CVE-2026-109619

Obie luki wynikają z błędów w sposobie, w jaki silnik PHP przetwarza wewnętrzne dane żądań. Nie są to błędy we wtyczkach, motywach ani samej aplikacji, lecz usterki samego środowiska PHP.

Pierwsza z luk, CVE-2026-109618, wiąże się ze stanem braku pamięci. Przerwanie pracy PHP w momencie, gdy dane żądania są tylko częściowo zainicjalizowane, prowadzi do błędu podczas czyszczenia zasobów. Proces czyszczenia PHP traktuje niekompletne dane jako prawidłowe, co wywołuje uszkodzenie pamięci i stwarza możliwość zdalnego wykonania kodu.

Druga luka, CVE-2026-109619, dotyczy nieaktualnego stanu wewnętrznego. Proces roboczy PHP może zachować odniesienie do danych żądania po zwolnieniu pamięci. Kolejne żądanie obsługiwane przez ten sam proces roboczy uzyskuje dostęp do tych nieaktualnych informacji przed ich zresetowaniem. Prowadzi to do ujawnienia informacji lub zdalnego wykonania kodu.

Zagrożone są wszystkie instalacje PHP obsługujące ruch sieciowy, w tym PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP oraz LiteSpeed. PHP uznaje ryzyko za najwyższe w przypadku mod_php, gdzie żądanie od niezalogowanego użytkownika wywołuje błąd jeszcze przed uruchomieniem kodu aplikacji.

W sieci zarejestrowano próby wykorzystania tych luk pod nazwą php2shell. Firma Hadrian oraz inne firmy z branży bezpieczeństwa, w tym Cloudflare, WatchTowr, Patchstack i Vega, zgłosiły próby eksploatacji. Najczęściej atakujący wykorzystują ścieżkę postępu przesyłania plików w sesji PHP.

Aktualizacja środowiska PHP i wersje z poprawkami

Aby wyeliminować podatność, należy zainstalować wydaną wersję środowiska PHP. Zespół PHP opublikował następujące wydania zawierające poprawki:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

W przypadku starszych gałęzi, takich jak PHP 7.4, PHP 8.0 oraz PHP 8.1, wydano awaryjne poprawki wsteczne w kodzie źródłowym. Dostawcy dystrybucji Linuksa oraz dostawcy wsparcia długoterminowego (LTS) mogą również dostarczać załatane pakiety.

Samo podniesienie wersji aplikacji, wtyczek czy motywów nie chroni serwera. Konieczna jest załatana kompilacja PHP uruchomiona na serwerze. Osoby zarządzające własnym serwerem lub VPS powinny wykonać następujące kroki:

1. Zainstalować odpowiednią wersję PHP przy użyciu systemu operacyjnego, panelu zarządzania hostingiem lub dostawcy pakietów.
2. Zrestartować lub przeładować procesy robocze PHP i powiązane usługi, aby korzystały z załatanej wersji.
3. Sprawdzić wersję PHP faktycznie obsługującą witrynę. Wersja w wierszu poleceń sprawdzana komendą php -v może różnić się od wersji używanej przez serwer WWW.
4. Przetestować kluczowe funkjce, w tym logowanie, finalizację zamówień, formularze, przesyłanie plików, zaplanowane zadania, interfejsy API oraz strony administracyjne.

W przypadku korzystania z hostingu współdzielonego należy sprawdzić panel zarządzania pod kątem wyboru wersji PHP lub skontaktować się z dostawcą usługi.

Tymczasowe zabezpieczenia i ograniczenia zapory WAF

Jedynym pełnym rozwiązaniem jest aktualizacja środowiska PHP. Jeśli natychmiastowa instalacja nowej wersji nie jest możliwa, można zastosować tymczasowe środki zaradcze.

Administratorzy mogą wyłączyć funkcję śledzenia postępu przesyłania plików na poziomie serwera w pliku php.ini lub w konfiguracji puli FPM:

session.upload_progress.enabled = Off

Po zmianie konfiguracji konieczne jest ponowne uruchomienie wszystkich procesów roboczych PHP. Ta zmiana ma jednak istotne ograniczenia: blokuje jedynie potwierdzone ścieżki ataku dla CVE-2026-109619 wykorzystujące sesje, nie chroni przed wszystkimi wariantami tej luki i nie zabezpiecza przed luką CVE-2026-109618.

Reguły zapory Sucuri WAF blokują znane wzorce ataków php2shell przed dotarciem do podatnego środowiska PHP. WAF stanowi dodatkową warstwę ochrony na czas wdrożenia aktualizacji, ale nie zastępuje łatania.

Zapora WAF działa tylko wtedy, gdy ruch przechodzi przez zaporę. Aby zapobiec obejściu zapory przez atakujących, należy upewnić się, że:

• Ograniczono bezpośredni dostęp IPv4 i IPv6 do serwera źródłowego.
• Serwer źródłowy akceptuje ruch sieciowy wyłącznie z zatwierdzonych adresów Sucuri Firewall.
• Alternatywne nazwy hostów, stare rekordy DNS, środowiska testowe, deweloperskie, stagingowe i kopie zapasowe nie wystawiają serwera źródłowego.