Krytyczne luki w PHP. Są już poprawki, także dla starszych wersji

21 października 2026 r. projekt PHP opublikował pilne aktualizacje usuwające dwie krytyczne podatności: CVE-2026-109618 i CVE-2026-109619. W odpowiednich warunkach pozwalają one atakującemu wykonać kod na serwerze bez logowania. CloudLinux przygotował również poprawki dla starszych gałęzi PHP, których sam projekt nie obejmuje już regularnym wsparciem.

Co się stało i kogo dotyczy problem?

Obie luki, określane również nazwą PHP2Shell, dotyczą samego interpretera PHP. Każda otrzymała ocenę 9,2 w skali CVSS 4.0. Oficjalny komunikat obejmuje wszystkie instalacje PHP obsługujące żądania WWW, w tym PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Nie oznacza to jednak identycznego scenariusza ataku w każdej konfiguracji. Zespół PHP wskazuje najwyższe ryzyko dla mod_php, gdzie pokazano atak uruchamiany jeszcze przed wykonaniem kodu aplikacji.

Pierwszy problem, CVE-2026-109618, wiąże się z obsługą braku pamięci. Przerwanie operacji w nieodpowiednim momencie może pozostawić niekompletne dane wewnętrzne, które PHP później potraktuje jak prawidłowe. Potwierdzony skutek obejmuje wykonanie kodu z uprawnieniami procesu obsługującego żądania WWW. Nie jest to automatycznie przejęcie uprawnień administratora całego serwera, ale nadal oznacza poważne naruszenie bezpieczeństwa.

CVE-2026-109619 dotyczy stanu wewnętrznego, który może przetrwać po zwolnieniu przypisanej mu pamięci. Kolejne żądanie trafiające do tego samego procesu może odwołać się do tych nieaktualnych danych. Taki błąd typu use-after-free również może prowadzić do zdalnego wykonania kodu.

Publikację poprawek przyspieszono o jeden dzień. PHP Foundation wyjaśnia, że pierwotny termin przypadał na 22 października, ale identyfikatory luk zaczęły krążyć publicznie 20 października. Dystrybucje Linuksa i dostawcy długoterminowego wsparcia otrzymali poprawki wcześniej, aby przygotować własne pakiety.

Które wersje PHP zawierają poprawki?

Dla gałęzi wspieranych przez projekt PHP wydano następujące wersje:

• PHP 8.2.35;
• PHP 8.3.36;
• PHP 8.4.27;
• PHP 8.5.12.

Chodzi o aktualizację w obrębie używanej gałęzi, nie o konieczność natychmiastowego przenoszenia każdej strony na PHP 8.5.

Wyjątkowo zespół bezpieczeństwa PHP udostępnił także minimalne poprawki kodu źródłowego dla PHP 7.4, 8.0 i 8.1. Nie oznacza to przywrócenia regularnego wsparcia tych wersji ani wydania gotowych pakietów dla każdego środowiska.

CloudLinux łata także starsze PHP

CloudLinux i TuxCare dostarczyły poprawki również dla starych interpreterów. Według strony statusowej pełne wydanie poprawionych pakietów alt-php do stabilnych repozytoriów CloudLinux OS zakończyło się 22 października o 00:07 UTC, czyli o 02:07 czasu polskiego. Dla CloudLinux OS 7, 8 i 9 wskazano serie 5.2–5.6, 7.0–7.4 oraz 8.0–8.5. Poprawki objęły też rodzinę ea-php używaną z cPanel EasyApache 4.

To backporty: dostawca przenosi poprawkę bezpieczeństwa do starszej wersji, zamiast wymuszać zmianę głównej gałęzi PHP. Numer widoczny w panelu nie zawsze musi więc odpowiadać numerowi nowego wydania z php.net. CloudLinux zaleca sprawdzenie konkretnego pakietu i wpisów dotyczących obu CVE w jego changelogu.

Trzeba przy tym rozróżnić alt-php, ea-php i natywne pakiety PHP systemu operacyjnego. W aktualizacji statusu z 22 października, 09:21 UTC, CloudLinux zaznaczył, że część natywnych pakietów nadal pozostawała w kanale testowym. Nie należy zatem odczytywać komunikatu o dostępności alt-php jako potwierdzenia, że poprawiono już każdy wariant PHP na każdym serwerze.

WAF pomaga, ale nie zastępuje aktualizacji

CloudLinux opisał również reguły Imunify360 blokujące znane żądania wykorzystujące podatności. Dostawca określa je jako zabezpieczenie tymczasowe, a nie usunięcie błędu. Z kolei CISA wezwała administratorów do pilnego wdrożenia poprawek, z priorytetem dla systemów dostępnych z internetu.

Po stronie hostingu zadanie nie kończy się na pobraniu pakietu. CloudLinux zaleca po aktualizacji restart odpowiednich usług PHP lub serwera WWW. Dopiero wtedy działające procesy korzystają z poprawionego interpretera. Właściciel strony powinien więc pytać o załatanie obu konkretnych CVE w środowisku obsługującym jego witrynę, a nie tylko o to, czy hosting „ma nowe PHP”.

Hostingi zareagowały szybko. Są konkretne potwierdzenia

W przeglądzie publicznych komunikatów 12 znanych marek hostingowych znaleźliśmy siedem deklaracji zakończenia wdrożenia w opisanym przez dostawcę zakresie. Stan sprawdzaliśmy 22 października około południa. To przegląd komunikatów, a nie techniczny audyt wszystkich serwerów.

• Smarthost podał, że aktualizacje zakończono 21 października około 23:59, a wszystkie wersje PHP w opisanych systemach otrzymały łaty.
• dhosting poinformował o zakończeniu prac 22 października o 03:57. Aktualizacje CloudLinux objęły wszystkie serwery WWW i obsługiwane linie PHP 5.3–8.5.
• Zenbox w aktualizacji komunikatu z 22 października, 05:12, potwierdził zakończenie prac nad wszystkimi wersjami interpreterów na wszystkich swoich serwerach.
• cyber_Folks ogłosił zakończenie wdrażania poprawek dla obu luk, także w środowiskach używających PHP 5.x i 7.x.
• home.pl potwierdził aktualizację zarządzanych platform, w tym starszych PHP. Osobno przypomniał, że klienci samodzielnie administrujący VPS-em lub serwerem dedykowanym muszą zaktualizować własne środowiska.
• SEOHOST zadeklarował zabezpieczenie wszystkich wersji PHP na hostingu współdzielonym dzięki poprawkom CloudLinux.
• MyDevil opisał wdrożenie zabezpieczonych interpreterów po testach, również dla starszych wersji PHP 5.6–7.3.

Brak znalezionego publicznego potwierdzenia u innego dostawcy nie oznacza, że nie zainstalował on łatek. Podobnie komunikat o ochronie WAF nie jest jeszcze potwierdzeniem aktualizacji PHP.

Dobra reakcja teraz, regularne aktualizacje w przyszłości

Na podstawie tych komunikatów większość sprawdzonych przez nas znanych marek poradziła sobie z sytuacją dobrze: potwierdziła wdrożenie nowych wersji lub poprawionych pakietów najpóźniej następnego dnia po publikacji łatek. Za szybką reakcję i uwzględnienie starszych PHP należy się pochwała. To ocena naszej próby, nie całego rynku.

Pozostaje też planowanie kolejnych aktualizacji. Oficjalne wsparcie bezpieczeństwa PHP 8.2 kończy się 31 grudnia 2026 r. Dodatkowe wsparcie dostawcy może pomóc utrzymać starszą aplikację, ale klient powinien wiedzieć, kto dostarcza poprawki i jak długo będzie to robił.

Mamy nadzieję, że ta mobilizacja przełoży się na równie konsekwentne pilnowanie aktualizacji PHP w przyszłości. Takiej dbałości potrzeba nie tylko przy głośnych, krytycznych lukach, ale również przy zwykłych wydaniach bezpieczeństwa. Klient nie powinien za każdym razem przypominać operatorowi o łataniu środowiska, za które płaci. Szybka aktualizacja powinna być standardem usługi, a nie jednorazową reakcją na alarm.