21 października 2026 r. PHP opublikowało poprawki dla dwóch krytycznych luk: CVE-2026-109618 i CVE-2026-109619. Mogą one umożliwić zdalne wykonanie kodu bez uwierzytelnienia w instalacjach PHP obsługujących żądania WWW. Administratorzy powinni dopasować aktualizację do używanej gałęzi, a w przypadku pakietów dystrybucji, hostingu lub urządzeń sprawdzić poprawkę u odpowiedzialnego dostawcy.

Na czym polega ryzyko w PHP

Anglojęzyczne omówienie Kevina Powella przedstawia wydanie poprawek PHP i problemy, z którymi mierzą się administratorzy.

PHP uznało za zagrożone wszystkie instalacje obsługujące żądania WWW. Wśród wymienionych konfiguracji są PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. PHP wskazało Apache z mod_php jako konfigurację o najwyższym ryzyku spośród wymienionych.

Luka CVE-2026-109618 dotyczy obsługi braku pamięci. Przerwanie działania PHP w chwili, gdy dane żądania są tylko częściowo zainicjowane, może sprawić, że procedura czyszczenia potraktuje nieprawidłowe dane jako poprawne. W przypadku CVE-2026-109619 wewnętrzny stan żądania może pozostać po zwolnieniu pamięci, która go przechowywała. Kolejne żądanie obsłużone przez ten sam proces roboczy może wtedy użyć nieaktualnego stanu.

Anglojęzyczne omówienie Kevina Powella przedstawia wydanie poprawek PHP i problemy, z którymi mierzą się administratorzy.

Poprawione wydania PHP

PHP opublikowało poprawki upstream, czyli wydania projektu, dla czterech gałęzi:

Gałąź PHPPoprawione wydanie
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

W przypadku PHP 8.1 i starszych gałęzi sam numer wersji nie przesądza o stanie pakietu. Projekt PHP nie publikuje już dla nich aktualizacji, ale niektóre dystrybucje i dostawcy wsparcia długoterminowego przygotowują własne poprawki, czyli backporty. Administrator powinien sprawdzić pakiet u dostawcy systemu, hostingu lub oprogramowania. NCSC zaleca też uwzględnić urządzenia i usługi, które mają PHP wbudowane.

Jak ograniczyć ryzyko przed aktualizacją

PHP podało tymczasowe ustawienia osobno dla obu luk, ale zaznaczyło, że nie zastępują one poprawki. Dla CVE-2026-109618 zaleca ustawienie memory_limit=-1 w konfiguracji, której aplikacja nie może nadpisać, oraz ograniczenie rozmiaru treści żądania. PHP ostrzega, że awaria alokacji pamięci na niższym poziomie nadal może uruchomić podatną ścieżkę.

Dla CVE-2026-109619 PHP zaleca wyłączenie session.upload_progress przed parsowaniem żądania i ponowne uruchomienie procesów roboczych. W PHP 8.5 wskazuje również fatal_error_backtraces=0 dla potwierdzonej ścieżki związanej ze śledzeniem stosu przy błędzie krytycznym. PHP uznaje aktualizację za jedyne kompletne rozwiązanie.

Jeśli nie da się od razu wdrożyć poprawki, NCSC zaleca zinwentaryzować instalacje PHP i w pierwszej kolejności sprawdzić systemy dostępne z internetu. Następnie należy zastosować aktualizację lub tymczasowe środki PHP. Gdy nie można wdrożyć ani jednego, ani drugiego, NCSC zaleca rozważyć odłączenie systemu. Jeśli nie da się go od razu zaktualizować ani wyłączyć, trzeba sprawdzić go pod kątem przejęcia i backdoorów podczas działań naprawczych. Wskazówki NCSC dotyczące luk PHP obejmują także śledzenie aktualizacji urządzeń i usług dostarczanych przez zewnętrznych dostawców.

Kto powinien wdrożyć poprawkę

Luki dotyczą PHP działającego po stronie serwera, więc odwiedzający witrynę nie może samodzielnie zainstalować poprawki. Za aktualizację odpowiada organizacja zarządzająca daną instalacją PHP. Gdy systemem lub pakietem zarządza dostawca hostingu albo producent urządzenia, administrator powinien ustalić, którą gałąź i pakiet utrzymuje ten dostawca.